Im a developer for the upcoming space telescope NEO Surveyor (Near Earth Object Surveyor). I actually work quite a bit with a number of people on the team up at JPL, Horizons is the canonical source for ephemeris information. Another vital part of the chain is the Minor Planet Center (MPC), which is where all observations of asteroids and comets are sent by the community. The MPC is the international authority for these observations, which JPL ingests and computes orbits for (though the MPC also has to compute orbits as a part of their work).
As a part of my work I have written a rust/python package[1] to compute the position of asteroids accurately using the ephemeris data provided by these two excellent sources. For the people who use SPICE kernels (a rather old binary format for storing orbital ephemeris), I have also written a custom implementation of spice kernel reading which is natively parallel.
Is there an explanation somewhere of how JPL knows/receives the latest satellite position data?
I think I've read about maneuvers being sent in advance, but once a maneuver (or flyby) actually happens (which may result in deviations from the plan), how (fast) does the ephemeris data actually align with reality through measurement of the actual spacecraft position and speeds again?
Sorry, I know some of the ways measurements are taken for satellite orbits, but not who actually does them or how that information makes its way to JPL.
Do you know -- is the SPICE API or HORIZONS API available for public use (i.e. within an app)? And if so where can I read about getting an API key / usage limitations (rate limits etc)
SPICE itself is a C package with a number of wrappers in other languages. JPL use it, along with numerical integrator and orbit determination code to generate SPICE "kernels", IE: binary files. The Horizons API allow you to use their numerical integrators to calculate the position of asteroids and comets. This works great for single objects, or a handful, but struggles when you want to look at the entire solar system at a time. This is where my code comes in, it enables similar calculations to what Horizon's provides, but you can do them locally on all known asteroids/comets.
The C SPICE library is available online, but it dates back decades, and was not really built with multi-core support in mind. My code enables reading of SPICE kernel files with native multi-core support. Though I would argue the bigger benefit that my code provides is the numerical integrator which can be used on the entire asteroid belt at once.
JPL Horizons API is open to anyone, if you hammer it enough they may rate limit you, but I don't believe they have limits. As far as I am aware they don't have any API keys or usernames.
See: https://ssd-api.jpl.nasa.gov/doc/horizons.html
As a part of my work I have written a rust/python package[1] to compute the position of asteroids accurately using the ephemeris data provided by these two excellent sources. For the people who use SPICE kernels (a rather old binary format for storing orbital ephemeris), I have also written a custom implementation of spice kernel reading which is natively parallel.
[1] https://github.com/Caltech-IPAC/kete