Astrology API Accuracy: How to Read an Arcsecond Claim
Astrology API accuracy claims are comparable only with lineage, scope and worst case. Five questions, and an open benchmark that answers them per domain.
TL;DR
- An astrology API accuracy figure against NASA JPL Horizons is readable only with five things beside it: the lineage of the engine, the scope of what was measured, the sample and its span, the worst case, and whether the inputs and the runner are public.
- An API that wraps a calculation library and is checked against Horizons measures the library authors, not the vendor; checked against the library itself, it is a self-test. Neither tells a buyer what the vendor got right.
- Planet positions are one slice. Houses, sidereal frames, calendars, event instants and discrete rules each fail in their own way, so a claim that covers only positions covers a fraction of what an astrology API returns.
- The open RoxyAPI benchmark answers all five per domain. In the October 2026 run, every Sun, Moon, planet and Chiron position came back within 0.32 arcseconds (0.000089 degrees) of NASA JPL Horizons, and 2,701 of 2,701 values across 17 domain folders sat within their pass bands (live report).
Suppose two astrology APIs both publish a median deviation against NASA JPL Horizons. One reports a few hundredths of an arcsecond. The other reports a few arcseconds. Read as a ratio, the first looks like a different class of product. Read as a measurement, the two numbers may not measure the same thing at all. Astrology API accuracy is the one claim in this category that looks quantitative and is almost never comparable, because a deviation figure carries no meaning without the lineage of the engine, the scope of what was checked, the size and span of the sample, and the worst case behind the median. This post is the reading procedure. Apply it to any provider, including this one.
Why does a smaller arcsecond number not mean a more accurate astrology API?
A smaller deviation against NASA JPL Horizons can mean better agreement, or it can mean the measurement never reached the vendor at all. Those are different claims wearing the same unit, and until you know which one a published number is, the smaller figure is not evidence of anything.
Three cases cover almost every published figure in this category.
- A wrapper checked against the library it wraps. The API forwards arguments to a calculation library and compares its output with that library. Agreement shows the arguments were passed through. It is a self-test.
- A wrapper checked against NASA JPL Horizons. The agreement is real, but it belongs to the authors of the library; the vendor added a network hop. Those libraries are licensed copyleft or sold under a commercial licence, so the buyer also has to ask which licence reaches the product they ship.
- An engine that reads the NASA JPL ephemeris directly. Roxy Ephemeris is in this case: it reads the NASA JPL DE440 ephemeris directly, with no third party library in between. The planetary motion is the same integration Horizons serves, so a small median is expected, and what the comparison tests is everything between the ephemeris and a zodiac longitude: time scales, light time, aberration, precession, nutation and the frame of date. That chain is the work of the vendor, so the comparison measures the vendor end to end.
The full verification map, reference by reference, is on the methodology page.
Ready to build on positions you can audit? The RoxyAPI Astrology API gives you natal charts, horoscopes and transits on one key, with the benchmark that produced these numbers published under MIT. See pricing.
Which five questions make two accuracy claims comparable?
Ask these five, in this order, before you put two numbers side by side. A provider that answers all five has published a measurement. A provider that answers none has published a number. Four are answered by a methodology page, and the fifth by whether a repository exists.
| Question | Why it moves the number | How to check it |
|---|---|---|
| Lineage. Does the vendor compute positions, or forward them from a library? | A wrapper scores the library, or itself | Ask the provider to name the calculation engine and its data source. A bare "proprietary" is itself an answer |
| Scope. Which quantities were checked: positions only, or houses, sidereal frames, calendars and rules too? | Positions are one slice; most user-facing errors live in the layers above | Look for a separate authority and result per domain, not one figure for the whole API |
| Sample and span. How many values, charts, dates and latitudes? | Disagreement grows with epoch distance, slow outer bodies and high latitude; a modern, mid-latitude sample flatters everyone | Look for pre-1900 dates, both hemispheres, latitudes above 60 degrees, and the counts per quantity |
| Worst case. Is the maximum published beside the median, at the reference precision? | A median hides the tail, and a harness that rounds the reference turns small differences into noise | Look for the maximum per quantity and the chart behind it. NASA JPL Horizons prints seven decimal degrees, about 0.0004 arcseconds |
| Reproducibility. Are the inputs, the cited reference values and the runner public? | A number nobody can re-run is a claim | Look for a repository with the inputs, sourced references and a runner under a licence that lets you fork it |
Lineage decides whether the comparison reaches the vendor at all, and the worst case decides whether the gap between two small numbers means anything.
Largest deviation from NASA JPL Horizons over all 231 Sun, Moon, planet and Chiron positions in the October 2026 run of the open benchmark, median 0.048 arcseconds (0.000013 degrees). Reference values carry the seven decimal degrees Horizons prints, so every deviation is measured, not rounded.
What does the RoxyAPI benchmark actually measure?
The open benchmark measures RoxyAPI domain by domain, each against the authority that defines the quantity, and publishes every value in a live report and a PDF. In the October 2026 run it covered 17 domain folders and 2,701 values, every one within its pass band.
| Layer | Authority | October 2026 result |
|---|---|---|
| Sun, Moon, planets, Chiron | NASA JPL Horizons | 231 of 231 within 0.32 arcsec (0.000089 degrees), median 0.048 |
| Ascendant, Midheaven, Placidus cusps | Horizons sidereal time and obliquity, spherical astronomy | 200 of 200 within 1.5 arcsec (0.00042 degrees) |
| Vedic sidereal longitudes | Horizons with the Lahiri ayanamsa by its published definition | 230 of 230 within 1.5 arcsec (0.00042 degrees), median 0.039 |
| Event instants (ingress, station, transit) | NASA JPL Horizons | 29 of 29 within 45 seconds |
| Calendars and discrete rules | US Naval Observatory, Hong Kong Observatory, printed texts | Calendar dates match to the day; 1,728 of 1,728 discrete values exact |
Three things to read in the report. How the residual moves with the date: in an engine that reads the JPL ephemeris directly, what is left on old charts is the frame model. Horizons prints longitudes on the IAU 1976 and 1980 precession and nutation model, which drifts from the current IAU 2006 and 2000 model by about 0.3 arcseconds per century away from 2000, so the largest planet deviation sits on the 1879 chart. Where the maximum sits for angles: at high latitude a cusp magnifies any time difference, so the largest angle deviation is the Anchorage winter solstice chart. And the discrete layers: a nakshatra, a gate or a pillar is right or wrong, so those are exact matches with no tolerance at all.
A pass rate is not an accuracy figure. The planet pass band is 36 arcseconds, 72 for the Moon: a vendor neutral bar wide enough for two good ephemerides and tight enough to fail a wrong time zone or a geometric rather than an apparent position. A provider quoting only a pass rate has told you it cleared a bar. Read the maximum per quantity, which the report publishes.
The wider suite behind those numbers, including why house cusps are also pinned against a second authority, is the subject of the gold standard testing methodology. How the benchmark itself is built is in the benchmark post.
How do you run an accuracy benchmark against any astrology API yourself?
Four steps, and none needs our cooperation. The benchmark is MIT licensed and vendor agnostic, so the same references that measure RoxyAPI measure anyone who returns the same quantities.
- Clone and install.
git clone https://github.com/RoxyAPI/astrology-api-benchmark.git, thenuv sync. uv installs the right Python. - Read the references before the results. Each folder under
domains/holdsreferences.json, with every value, its source, its retrieval date and its pass band with the reason. - Run one domain or all. Put the key in
.env.localasROXY_API_KEY, thenuv run python -m benchmark run --domain western-planets. Without--domain, every domain runs. - Point it somewhere else. Add
--target https://api.example.com/v1 --out runs/exampleand adapt thecheck()function in that domain folder, the one place a response is read. References, pass bands and statistics stay fixed, so the provider is measured by the same numbers.
How to check a single position by hand
Resolve the birthplace first, because a chart built on a guessed offset fails on the time layer before the ephemeris gets a turn.
curl -s -H "X-API-Key: $ROXY_API_KEY" \
"https://roxyapi.com/api/v2/location/search?q=honolulu&limit=1"{"total":4,"limit":1,"offset":0,"cities":[{"city":"Honolulu","province":"Hawaii",
"country":"United States","iso2":"US","latitude":21.3069,"longitude":-157.8583,
"timezone":"Pacific/Honolulu","utcOffset":-10,"population":350964}]}Feed the coordinates and the IANA timezone name into the positions endpoint. Sending the IANA name lets the API resolve the historically correct offset for the chart date, which matters on any birth near a daylight saving edge.
curl -s -X POST https://roxyapi.com/api/v2/astrology/planets \
-H "Content-Type: application/json" \
-H "X-API-Key: $ROXY_API_KEY" \
-d '{"date":"1961-08-04","time":"19:24:00","latitude":21.3069,
"longitude":-157.8583,"timezone":"Pacific/Honolulu"}'Each entry of the returned planets array carries name, longitude, latitude, sign, degree, speed and isRetrograde. Full schemas are at POST /astrology/planets, runnable in the browser with no signup and no key.
That is the Barack Obama chart, case obama in the planet folder. Subtract each returned longitude from the matching reference in domains/western-planets/references.json, multiply by 3,600, and you have the deviation in arcseconds for every body. Do it for all of them and you see why a median alone is a poor summary: the residual is not spread evenly, and the report shows where it sits.
When is a smaller deviation genuinely better, and when is fidelity the right thing to want?
Two cases where the smaller number wins. When two engines are in the same lineage class, measured over the same quantities across the same span, a smaller maximum is straightforwardly better. And when two numbers differ by orders of magnitude rather than by a factor, lineage stops being an explanation and the larger figure needs one.
There is also a case where fidelity to a program is exactly what a buyer should want. If your product has to agree with a specific desktop program a practitioner already runs, because they will cross-check every chart, then agreement with NASA JPL Horizons is not your test. Agreement with that program is. Run both against your own charts and compare those outputs directly rather than two vendor medians against a third reference.
The limits on this side are worth stating too. The reference resolves far finer than our median, so two providers trading hundredths of an arcsecond are separated by lineage and frame model, not by the reference. And no deviation summary rules out a classification change: any nonzero difference can cross a sign, nakshatra or gate boundary when a position sits close enough to it, which is why the benchmark checks those discrete values separately as exact matches.
FAQ
Which astrology API is the most accurate?
No provider can honestly answer that from published medians alone, because the numbers are not comparable until lineage, scope, sample and worst case match. RoxyAPI publishes the parts that make an answer possible: the lineage (Roxy Ephemeris reads the NASA JPL DE440 ephemeris directly), a per-domain open benchmark with the maximum beside every median, and a runner anyone can point at any provider, including us.
What does arcsecond accuracy mean for an astrology API?
An arcsecond is one 3,600th of a degree. In the October 2026 run of the open benchmark, RoxyAPI returned every Sun, Moon, planet and Chiron position within 0.32 arcseconds (0.000089 degrees) of NASA JPL Horizons, far finer than the eye can resolve. Even a small nonzero deviation can change a classification when a position sits close to a sign, nakshatra or house boundary.
Why is a planet position check not enough to judge an astrology API?
Because users see houses, nakshatras, dasha dates, pillars and gates, and each is computed by a layer above the positions with its own convention and its own failure modes. A correct planet in a wrong frame is still a wrong chart. The RoxyAPI benchmark gives each domain its own authority, from Horizons sidereal time for house cusps to Hong Kong Observatory tables for the Chinese calendar.
How do I verify an astrology API myself?
Clone github.com/RoxyAPI/astrology-api-benchmark, run uv sync, then uv run python -m benchmark run against RoxyAPI. Point it at another provider with --target and --domain, adapting one check() function per domain. The references, with their sources, and the pass bands stay fixed, so the comparison is yours rather than ours.
Does a smaller median against NASA JPL Horizons mean a better ephemeris?
Not on its own. If the API wraps a library fitted to a NASA JPL ephemeris, a small deviation measures the library authors. If the engine reads the JPL ephemeris directly, as Roxy Ephemeris does, it measures the vendor chain from ephemeris to zodiac longitude, and what remains on old charts is the known frame model difference. Read the maximum and the lineage beside any median.
Conclusion
An astrology API accuracy claim is only as good as the five things around it, and every one is cheap to publish and cheap to check. RoxyAPI publishes all five per domain, plus the runner that reproduces them, alongside 18+ insight domains on one key, Remote MCP for agents, typed SDKs and flat pricing. Start with the RoxyAPI Astrology API, read the live report, and hold every provider to the same reading.