Astrology API Accuracy Benchmark vs NASA JPL Horizons DE441

About the author: Brett Calloway is a Developer Advocate and AI Integration Specialist with 12 years of experience building APIs and developer tooling, including three years focused on AI-native infrastructure for spiritual and wellness applications. He writes on building context-rich AI agents using Model Context Protocol, drawing on a developer relations background.

Astrology APIs make accuracy claims constantly. Almost none publish a reproducible benchmark. Buyers are asked to trust a methodology page or a tolerance number, with no public dataset, no runnable code, and no way to confirm the claim independently. That gap is where vendor trust dies. This benchmark closes it. We pulled 210 reference planet positions from NASA JPL Horizons DE441 across 21 birth charts, ran them against the RoxyAPI natal-chart endpoint, and published the entire pipeline as an MIT-licensed Python repo. Anyone can clone it, run it, point it at any other astrology API, and see the deviation per planet. The README has the headline numbers. This post explains the methodology, the dataset choices, and what the results actually say.

Why most astrology API accuracy claims cannot be verified

The standard accuracy claim in this category is a methodology page that lists tolerance thresholds and named reference sources, with no published data. A reader has no way to reproduce the test or confirm the numbers. That is not a benchmark. It is a marketing artifact.

A reproducible benchmark needs four things: chart inputs, expected reference values from a named authority, runnable code, and per-body deviation results. Most providers ship only the first two and call it methodology. We documented our internal verification methodology in the 828 gold-standard tests blog two years ago. This new benchmark goes further: the methodology AND the dataset AND the code, MIT licensed, anyone can re-run.

Ready to verify this yourself? RoxyAPI Astrology API returns the planet positions you can plug straight into the benchmark. See pricing.

What this benchmark validates and what it deliberately does not

This benchmark validates two specific layers of any astrology API. First, the timezone conversion layer: given a local birth time and a decimal timezone offset, does the API resolve the same UTC moment that NASA JPL Horizons resolves? Wrong timezone math is the most common silent failure in astrology APIs and produces wrong planet positions even when the underlying ephemeris is correct. Second, the ephemeris layer: for the correct UTC moment, does the API compute geocentric ecliptic planet longitudes that match JPL Horizons DE441?

The 21-chart dataset and why named charts matter

The dataset balances credibility with coverage. Eight named celebrity birth charts come from astro-databank with explicit Rodden Ratings: Barack Obama (AA), Beyoncé Knowles (AA), Albert Einstein (AA), Marilyn Monroe (AA), Steve Jobs (AA), Princess Diana (A), John F Kennedy (A), and Elon Musk (B). Anyone can cross-check our birth-time inputs against the same astro-databank entries. Thirteen synthetic edge-case charts cover what celebrity charts miss: Reykjavík and Tromsø above the Arctic Circle, Anchorage at 61 degrees north, Ushuaia at 55 degrees south, Quito on the equator, New York DST spring-forward and fall-back, Mumbai with the half-hour IST offset, Sydney AEDT, Tokyo JST, Boston in 1900, Greenwich at the Y2K rollover, and the Samoa post-2011 calendar skip. The dataset spans 1879 to 2011, six continents, both hemispheres, the equator, three high-latitude locations above 60 degrees, both DST transition edges, and a half-hour timezone offset. Coverage is the goal, not volume.

Why NASA JPL Horizons DE441 is the authoritative reference

NASA JPL Horizons is the authoritative ephemeris reference for solar system body positions. The DE441 ephemeris is the modern numerical-integration solution maintained by the Solar System Dynamics group at the Jet Propulsion Laboratory. It is the same data spacecraft missions navigate against, with sub-arcsecond agreement for the bodies astrology cares about. When a reference dataset disagrees with JPL Horizons, the reference is wrong, not JPL.

There is one nuance worth stating clearly. JPL Horizons is the authoritative reference for raw planet positions, not for the full astrology stack. Layers built on top of the planet layer (house cusps, ascendant, midheaven, ayanamsa selection, dashas, doshas, divisional charts, panchang, KP sub lords, interpretations) are domain-specific transforms verified separately against named domain authorities. The benchmark validates the foundational planet-position layer that everything else depends on. If the planets are wrong, every layer above is wrong. If the planets match JPL, the rest of the stack inherits a clean foundation.

Headline numbers and what they reveal

The benchmark ran against the RoxyAPI natal-chart endpoint on 2026-04-28. Every reference point passed.

The deviation is driven by ephemeris-implementation differences at the arcsecond level, not methodology gaps. Numbers reproduce on every run within the precision JPL Horizons publishes.

How to run the benchmark against any astrology API

The benchmark is vendor-agnostic by design. The default target is RoxyAPI; pointing the script at any other astrology API takes one flag. Per the canonical API route verification rule, every chart endpoint that needs coordinates expects a prior call to a geocoding service so users do not type latitude and longitude by hand.

# Step 1: geocode the birth city
curl -s "https://roxyapi.com/api/v2/location/search?q=Honolulu" \
  -H "X-API-Key: $ROXY_API_KEY"

# Step 2: natal chart with the resolved coordinates
curl -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}'

import os, urllib.request, json

key = os.environ['ROXY_API_KEY']

# Step 1: geocode
geo = urllib.request.urlopen(
    f"https://roxyapi.com/api/v2/location/search?q=Honolulu",
    headers={"X-API-Key": key},
)
city = json.loads(geo.read())["cities"][0]

# Step 2: natal chart
req = urllib.request.Request(
    url="https://roxyapi.com/api/v2/astrology/natal-chart",
    data=json.dumps({
        "date": "1961-08-04", "time": "19:24:00",
        "latitude": city["latitude"], "longitude": city["longitude"],
        "timezone": city["timezone"],
    }).encode(),
    headers={"Content-Type": "application/json", "X-API-Key": key},
    method="POST",
)
chart = json.loads(urllib.request.urlopen(req).read())

The full benchmark clones in seconds: git clone https://github.com/RoxyAPI/astrology-api-benchmark.git && cd astrology-api-benchmark && python3 benchmark.py. Three CSV files (charts.csv, expected.csv, results.csv), one Python script, no external dependencies. Read the spec for the natal-chart endpoint to map fields if you adapt the script for another API.

Frequently Asked Questions

Q: How accurate is RoxyAPI compared to NASA JPL Horizons? A: Median deviation is 0.27 arcmin (16 arcseconds) across 210 planet positions in 21 charts. Maximum is 0.54 arcmin (32 arcseconds), well inside the 0.05 degree tolerance band for outer planets. The Moon, the fastest-moving body, lands within 0.05 arcmin (3 arcseconds) on every chart. All numbers reproduce within the precision JPL Horizons publishes for DE441.

Q: Can I run this benchmark against any astrology API? A: Yes. The script is vendor-agnostic. Set --base-url and --natal-path to point at a different API, and adapt the response-parsing function if the response shape differs from the default. The function is 25 lines and isolated. The repo is MIT licensed: clone, modify, and republish results as you see fit.

Q: Why does this benchmark not validate house cusps or ascendant? A: JPL Horizons publishes geocentric ecliptic positions for solar system bodies. It does not compute observer-frame angles like ascendant, midheaven, or house cusps because those depend on local sidereal time, obliquity model, and house-system choice. House cusps are validated separately against published Western astrology references and are part of the broader methodology.

Q: What ephemeris does the calculation engine actually use? A: Roxy Ephemeris is the proprietary in-house engine that powers all RoxyAPI calculations. It is verified against NASA JPL Horizons DE441, the same authoritative reference used in this benchmark. There is no AGPL obligation, no copyleft, and no commercial-license requirement passed to API consumers. See the methodology page for the full architecture.

Q: Where do I find the dataset and code? A: Everything is at github.com/RoxyAPI/astrology-api-benchmark. Three CSV files, one Python script, an MIT license, and a README with the latest baseline run. Pull requests are welcome to grow the dataset toward 50 and then 100 charts as the next milestones.

Conclusion

Sub-arcminute accuracy against the authoritative ephemeris is a verifiable claim, not a marketing tagline. The MIT-licensed benchmark turns it into a number any developer can reproduce in 30 seconds. Run it against RoxyAPI today.