Astrology API Accuracy Benchmark: Every Domain, Every Source

The astrology API accuracy benchmark is an open, MIT licensed repository that measures what an astrology API returns against the authority that defines each quantity: NASA JPL Horizons for planets, angles and sidereal positions, the US Naval Observatory for sunrise and moon phases, the Hong Kong Observatory for the Chinese calendar, and printed tables and definitions for rule based domains. RoxyAPI first published it in April 2026 as a planet position check. It is now one folder per domain, because planet longitudes are one slice of what an astrology API computes, and the slices a buyer ships to users (houses, nakshatras, dasha dates, pillars, gates, calendar days) fail in their own ways and need their own authority. This post explains what the benchmark measures, what does not count as an accuracy check, how to read the report, and how to run it against any provider.

How accurate is RoxyAPI against NASA JPL Horizons?

RoxyAPI returned every Sun, Moon, planet and Chiron position in the October 2026 run within 0.32 arcseconds (0.000089 degrees) of NASA JPL Horizons: 231 of 231 across 21 charts from 1879 to 2011, median 0.048 arcseconds (0.000013 degrees). The worst case is published, not hidden: Pluto on the 1879 Albert Einstein chart.

What remains on the oldest chart is the reference frame model, not an ephemeris difference. Roxy Ephemeris reads the NASA JPL DE440 ephemeris directly, so the planetary motion is the same integration Horizons serves. 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 1879 chart carries the most of it.

The angles derived from those positions hold to the same order. Ascendant, Midheaven and Placidus cusps, computed from Horizons sidereal time and obliquity with the published spherical astronomy formulas, came back 200 of 200 within 1.5 arcseconds (0.00042 degrees), the largest at the Anchorage winter solstice chart, where a high latitude magnifies any time difference. The methodology page carries the verification register behind every domain.

Ready to build on positions you can audit? The RoxyAPI Astrology API returns the chart the benchmark measures, on the same key as 18+ insight domains. See pricing.

What does the benchmark check beyond planet positions?

Every computed domain gets its own folder, its own authority and its own pass band, and each quantity is measured in its own unit: arcseconds for angles, seconds for instants, days for calendar counts, exact match for discrete values. In the October 2026 run that came to 661 angles with a median of 0.048 arcseconds, 133 instants with a median of 1.6 seconds, 179 calendar counts with a median of 0 days, and 1,728 of 1,728 discrete values exact.

Tarot, crystals, dreams and angel numbers are not in the run: they return curated content or seeded draws, so there is no outside value to measure them against. Pass bands are vendor neutral floors, never sized to one implementation, so the report prints the median, the 95th percentile and the maximum per quantity beside the pass count. A pass rate alone tells you a provider cleared a bar; the maximum tells you by how much.

What does not count as an astrology API accuracy check?

A check counts only when the reference is independent of the code being checked and the worst case is published. Most published accuracy claims in this category fail one of those two tests, and the failure modes are structural rather than a matter of effort.

• An astrology API checked against the calculation library it wraps is a self-test. It shows that the wrapper passes arguments through and says nothing about whether the numbers are right.
• An astrology API that wraps a calculation library and is checked against NASA JPL Horizons measures the library, not the vendor. The agreement belongs to the authors of the library; the vendor added a network hop.
• The widely used astrology calculation libraries are licensed copyleft or sold under a commercial licence. A buyer of an API built on one has to ask which of the two applies to the product they ship. RoxyAPI reads the NASA JPL DE440 ephemeris directly with no third party library in between, so a comparison with Horizons measures RoxyAPI work end to end and passes no copyleft obligation to the buyer (licence).
• A check that drops the bodies, dates or charts where its numbers look worse, or publishes only a median, hides its worst case. This benchmark keeps Chiron and the 1879 chart in, and prints the maximum beside the median.
• Planet positions alone are one slice. Angles, sidereal frames, calendars, time zones and discrete rules each need their own authority, which is why the benchmark is organised by domain.

The same reasoning, applied to comparing two published figures, is the subject of how to read an arcsecond claim.

How is each reference value sourced?

Every domain commits its reference values with the source, the retrieval date and the licence, and the runner reads those committed files only; it never contacts a reference server during a run. Machine sources such as NASA JPL Horizons are pulled by a script in the domain folder. Rule based domains are recomputed from the published definition, and a second source is transcribed as cross checks the recomputation must reproduce.

Two choices on the planets are worth knowing before you compare against your own pulls. Positions are apparent geocentric ecliptic longitudes of date, read at seven decimal degrees as Horizons prints them. Jupiter to Pluto are compared with the Horizons system barycentres, which is what a planetary ephemeris integrates, because the Horizons planet centres come from separate satellite solutions that sit thousands of kilometres off it.

The time layer is part of the test. The API receives the local birth time with its UTC offset or IANA zone name, exactly as a user would send it, while the reference is computed at the UT instant. A wrong time zone resolution moves every position, and the Moon, at about 13 degrees a day, shows it first. The shared chart set mixes named charts with AA, A and B Rodden ratings and synthetic edge cases: daylight saving gaps and overlaps, local mean time before standard zones, a half hour offset, latitudes above 60 degrees and the Samoa skipped day.

What changed since the April 2026 edition?

The April edition checked 210 planet longitudes on the same 21 charts and reported a median of 0.05 arcseconds. The rebuild added Chiron to the planet folder and sixteen more domain folders, and replaced one reference choice: the April run compared Jupiter to Pluto with their Horizons planet centres, and for Uranus on the 1879 chart that centre sits about 6,000 kilometres off the system barycentre a planetary ephemeris integrates. That reference side offset, on top of the frame model term, produced the April maximum. With the barycentres, the largest planet deviation is the frame model term on the same chart, 0.32 arcseconds (0.000089 degrees).

The structure also changed. The April harness was one script and three CSV files. The current runner is a Python package with one folder per domain, a JSON and CSV result per run, a self contained HTML report, and a scheduled workflow that reruns it monthly and republishes the README, the report page, the PDF and a tagged release. Older citations of 210 positions describe the April edition; the live report is the current one.

How do you run the benchmark against any astrology API?

Install uv, clone the repository, put a key in .env.local, and run every domain or one. The runner exits nonzero when any value fails or is missing, and writes results/latest.json and results/latest.csv.

git clone https://github.com/RoxyAPI/astrology-api-benchmark.git
cd astrology-api-benchmark
uv sync
echo "ROXY_API_KEY=your_key_here" > .env.local
uv run python -m benchmark run
uv run python -m benchmark site   # writes dist/index.html, the report page

Many astrology APIs cover a single domain, so run only the folder that matches what a provider sells. --domain repeats, --target changes the base URL, and the check() function in each domain folder is the one place a response is read, so adapting to another response shape is one function per domain. The references, pass bands and statistics stay exactly as they are, so a single domain provider is measured by the same numbers as the full RoxyAPI run.

uv run python -m benchmark run --domain western-planets --domain western-angles
uv run python -m benchmark run --target https://api.example.com/v1 --domain western-planets --out runs/example

To check one chart by hand, resolve the birthplace and call the natal chart endpoint. The Barack Obama chart below is case obama in the planet folder.

curl -s "https://roxyapi.com/api/v2/location/search?q=Honolulu&limit=1" \
  -H "X-API-Key: $ROXY_API_KEY"

curl -s -X POST "https://roxyapi.com/api/v2/astrology/natal-chart" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $ROXY_API_KEY" \
  -d '{"date":"1961-08-04","time":"19:24:00","latitude":21.3,"longitude":-157.8667,"timezone":-10}'

Each entry of planets carries name and longitude, and ascendant.longitude and midheaven.longitude carry the angles. The Sun returns 132.5479205 against a Horizons reference of 132.5479089: a deviation of 0.042 arcseconds. The full schema is at POST /astrology/natal-chart, where the playground runs it with no signup.

Frequently Asked Questions

Is there an open benchmark for astrology API accuracy?

Yes. The astrology API accuracy benchmark at github.com/RoxyAPI/astrology-api-benchmark is MIT licensed and checks an API domain by domain against cited authorities, from NASA JPL Horizons for planets to the Hong Kong Observatory for the Chinese calendar. It publishes every measurement in a live report and a PDF, and its runner points at any provider, one domain at a time.

How accurate is RoxyAPI compared to NASA JPL Horizons?

In the October 2026 run, RoxyAPI returned all 231 Sun, Moon, planet and Chiron positions within 0.32 arcseconds (0.000089 degrees) of NASA JPL Horizons, with a median of 0.048 arcseconds (0.000013 degrees). Ascendant, Midheaven and Placidus cusps came back within 1.5 arcseconds (0.00042 degrees). The report names the worst case for every quantity.

Which domains does the benchmark cover?

The October 2026 run covered 17 domain folders and 2,701 values: Western planets and angles, the Vedic sidereal chart, panchang, forecast instants, moon phases, Human Design, the Chinese calendar, feng shui, the Maya calendar, Vastu, numerology, Kabbalah, biorhythm, Ayurveda, I Ching and time zones. Tarot, crystals, dreams and angel numbers return curated content or seeded draws, so there is no outside value to measure.

Can I run the benchmark against another astrology API?

Yes. Run uv run python -m benchmark run --target <base URL> --domain <folder> and adapt the check() function in that domain folder, which is the one place a response is read. References, pass bands and statistics do not change, so a single domain provider is measured by the same numbers as the full run.

Why does the benchmark publish the maximum and not only the median?

A median hides the tail, and the tail is where two engines differ: old dates, slow outer planets, high latitudes. The report prints the median, the 95th percentile and the maximum per quantity, and names the chart behind the maximum, so a regression from 0.1 to 20 arcseconds is visible even though both pass.

How often is the benchmark rerun?

Every month, by a scheduled workflow against production. Each run rewrites the results, the README, the report page and the PDF, and tags a release, so the live report is always the latest figure and earlier runs stay in the release history.

Conclusion

An accuracy claim is worth what its references, its scope and its worst case are worth. The open benchmark publishes all three per domain, reruns them monthly, and runs against any provider. Read the live report, check the methodology, then build on the RoxyAPI Astrology API.