:::note
**TL;DR**
- An astrology API accuracy figure against NASA JPL Horizons is only readable with its lineage. An engine whose position data is a compressed fit of a NASA JPL development ephemeris is being measured against its own source, so a very small number there is the expected result, not a competitive one.
- Five questions make two medians comparable: what the engine derives from, how many positions and charts were measured, what dates and latitudes they span, what resolution the reference itself publishes, and whether the corpus and the script are public.
- NASA JPL Horizons publishes four decimal degrees, about 0.36 arcseconds. Any figure below roughly one arcsecond sits at the floor of the measurement rather than above a rival.
- The published RoxyAPI run is a 1.5 arcsecond median across 210 planet positions and 21 birth charts, shipped with its mean, its 95th percentile, its worst body and an MIT repository that reproduces it.
:::

Suppose two astrology APIs both publish a median deviation against NASA JPL Horizons. One reports a few hundredths of an arcsecond. The other reports 1.5. Read as a ratio, the first looks like a different class of product. Read as a measurement, the two numbers may not be measuring 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 size of the sample, the span of the dates, and the resolution of the reference itself. 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 engine being measured was derived from the reference it is being measured against. Those are two different claims wearing the same unit. Until you know which one a published number is, the comparison is arithmetic with no subject, and the smaller figure is not evidence of anything.

Production astrology engines fall into two lineages. In the first, planetary positions come from a compressed fit of a NASA JPL development ephemeris: the shipped data file is a compact re-encoding of the JPL series, and the authors of that method state in their own documentation that the compressed form agrees with its source to about a thousandth of an arcsecond. Measure that engine against JPL Horizons and you have measured compression fidelity. A tiny figure is the designed outcome, and a large one would be a defect.

In the second lineage, positions are derived independently and then checked against JPL Horizons. That figure is an agreement between two separate derivations, and it is the only one of the two that says anything about work JPL did not already do. Roxy Ephemeris is in the second lineage, which is why its published number is larger and why it means more. The full verification map, reference by reference, is on the [methodology page](/methodology "RoxyAPI verification methodology, reference sources and tolerance thresholds").

Ready to build on positions you can audit? [Roxy Astrology API](/products/astrology-api "production Western astrology API verified against NASA JPL Horizons") gives you natal charts, horoscopes and transits on one key, with the benchmark that produced these numbers published under MIT. [See pricing](/pricing "RoxyAPI plans and quotas").

## Which five questions make two accuracy medians 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. The questions are cheap: four of them 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.** What does the engine derive positions from, and does it share data with the reference? | An engine fitted to the reference is scoring its own compression, not its astronomy | Ask the provider to name the calculation engine and its data source. A refusal or a bare "proprietary" is itself the answer |
| **Sample size.** How many positions, across how many charts? | A median over ten positions from one chart is a spot check. The tail is where engines actually differ | Look for both counts. Positions alone hides how few charts were used |
| **Span.** Which dates, hemispheres and latitudes? | Ephemeris disagreement grows with epoch distance and with the slower bodies. A modern, mid-latitude sample flatters everyone | Look for pre-1900 dates, both hemispheres, and latitudes above 60 degrees |
| **Reference resolution.** What precision does the reference itself publish? | Below the floor of the reference, two providers are comparing quantization noise | NASA JPL Horizons publishes four decimal degrees, about 0.36 arcseconds |
| **Reproducibility.** Are the inputs, the expected values and the script public? | A number nobody can re-run is a claim. A number anyone can re-run is a measurement | Look for a repository with the chart inputs, the reference values and the runner, under a licence that lets you fork it |

Two of the five do most of the work. Lineage decides whether the comparison is legitimate at all, and reference resolution decides whether the gap between two small numbers exists.

:::stat 0.36 arcseconds
**The resolution floor of the reference.** NASA JPL Horizons publishes geocentric ecliptic longitude to four decimal degrees, so the open [astrology-api-benchmark](https://github.com/RoxyAPI/astrology-api-benchmark) cannot resolve a difference finer than this. Treat anything under roughly one arcsecond as at the floor.
:::

## What does the RoxyAPI benchmark actually measure, number by number?

The published run is 210 planet positions drawn from 21 birth charts, measured against NASA JPL Horizons DE441 on 30 July 2026, with all 210 points inside the published tolerance. The median deviation is 1.5 arcseconds, about 0.0004 degrees, far finer than the human eye can resolve and about 0.001 percent of a zodiac sign. Here is the whole distribution, not just the headline.

| Statistic | Arcseconds | Degrees | What it answers |
|---|---:|---:|---|
| Median | 1.5 | 0.0004 | the typical reference point |
| Mean | 2.7 | 0.0008 | whether the tail drags the average |
| 95th percentile | 11.2 | 0.0031 | the tail, which a maximum cannot describe |
| Maximum | 16.6 | 0.0046 | the single worst point, on Neptune |
| Maximum excluding Neptune and Uranus | 9.4 | 0.0026 | where the residual actually lives |
| Moon maximum | 3.3 | 0.0009 | the timezone layer, checked indirectly |

Three honest readings of that table. The residual is concentrated in the two slowest outer planets: Neptune and Uranus hold the entire top of the per-body results, and dropping them takes the worst case from 16.6 to 9.4 arcseconds. The Moon is the timezone check rather than an accuracy headline, because it moves about 13 degrees a day, so a wrongly resolved UTC moment would surface there before it surfaced anywhere else. And the median moved from 16.0 arcseconds on the first published run in April 2026 to 1.5 in July, about eleven times, on an unchanged dataset and an unchanged script, which is the only way an improvement figure is comparable to itself. Both runs stay side by side in the repository. The wider suite behind those positions, and the reason house cusps are verified against a different authority entirely, is the subject of the [gold standard testing methodology](/blogs/how-we-test-astrology-api-accuracy-828-gold-standard-tests "how RoxyAPI verifies every calculation against named external references").

:::warning
**A pass rate is not an accuracy figure.** All 210 points are inside tolerance, and the tolerance bands in this benchmark are 0.01 degrees for the planets and 0.02 degrees for the Moon. Those bands are a vendor-neutral pass bar, wide enough that any competent engine clears them and tight enough to catch a wrong timezone resolution or a geometric rather than an apparent ephemeris. A provider quoting only a pass rate has told you it cleared a bar it chose. Read the per-body numbers.
:::

## How do you run an accuracy benchmark against any astrology API yourself?

Five steps, and none of them needs our cooperation. The benchmark is MIT licensed and vendor agnostic by design, so the same corpus that measures Roxy Ephemeris measures anyone who returns planet longitudes for a natal chart. The runner is plain Python with no dependencies, so a first run is minutes of work rather than an afternoon.

1. **Clone the repository.** `git clone https://github.com/RoxyAPI/astrology-api-benchmark`. The runner uses the Python 3 standard library only, so there is nothing to install.
2. **Read the inputs before you trust the outputs.** `charts.csv` holds 21 rows, one per chart, with date, time, latitude, longitude, timezone offset and a Rodden rating. `expected.csv` holds 210 rows, one per body per chart, each carrying the reference longitude, its source and its tolerance.
3. **Run it.** `export API_KEY=...` then `python3 benchmark.py`. The run writes `results.csv`, one row per reference point, with the expected longitude, the returned longitude, the deviation in degrees and in arcseconds, and a pass or fail.
4. **Point it somewhere else.** `python3 benchmark.py --base-url https://example-api.com/api --natal-path /astrology/natal-chart`. If the response shape differs, one function in `benchmark.py` is the only place that knows about response structure.
5. **Enlarge the sample.** Append a row to `charts.csv` and run `python3 regenerate_expected.py`, which queries NASA JPL Horizons for every body at every chart moment and rewrites `expected.csv`. That is how you answer the sample size question for yourself rather than taking it on trust.

### How to check a single position by hand

Resolve the birthplace first, because a chart built on a guessed offset fails on the timezone layer before the ephemeris ever gets a turn.

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

```json
{"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 resolved coordinates and the IANA timezone name straight into the positions endpoint. Sending the IANA name rather than a numeric offset lets the API resolve the historically correct offset for the chart date, which matters on any birth near a daylight saving edge.

```bash
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 request and response schemas are at [`POST /astrology/planets`](/api-reference#tag/western-astrology/POST/astrology/planets "planetary positions endpoint with request and response schemas"), where you can run it live in the browser with no signup and no key.

Below is that call against the Obama chart, which is one of the 21, with the JPL reference values taken from `expected.csv` in the same repository. Ten bodies, one chart, captured on 20 September 2026.

| Body | Roxy Ephemeris | NASA JPL DE441 | Deviation |
|---|---:|---:|---:|
| Sun | 132.5477 | 132.5479 | 0.86 arcsec |
| Moon | 63.3577 | 63.3574 | 0.91 arcsec |
| Mercury | 122.3318 | 122.3316 | 0.65 arcsec |
| Venus | 91.7894 | 91.7893 | 0.53 arcsec |
| Mars | 172.5768 | 172.5766 | 0.69 arcsec |
| Jupiter | 300.8582 | 300.8586 | 1.28 arcsec |
| Saturn | 295.3305 | 295.3307 | 0.60 arcsec |
| Uranus | 145.2712 | 145.2708 | 1.36 arcsec |
| Neptune | 218.6024 | 218.6059 | 12.45 arcsec |
| Pluto | 156.9782 | 156.9778 | 1.41 arcsec |

Nine bodies inside 1.5 arcseconds, and Neptune at 12.45. That single row is the whole shape of the residual in one chart, and it is also the reason a median alone is a poor summary of any engine.

## When is a smaller deviation genuinely better, and when is fidelity the right thing to want?

Two cases where the smaller number wins, and both are worth saying out loud. When two engines are in the same lineage class, measured over the same corpus across the same span, a smaller median is straightforwardly better and the comparison is legitimate. And when the 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 a fidelity figure 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 you serve them, then agreement with NASA JPL Horizons is not your test. Agreement with that program is. Ask the provider what it reproduces, run both against your own charts, and compare those outputs directly rather than comparing two vendor medians against a third reference neither of you is really talking about.

The limits on this side are worth stating too. Below roughly one arcsecond, this benchmark cannot resolve a difference at all, so two providers trading hundredths are comparing the quantization of the reference. Our own residual is concentrated in the two slowest bodies in the set. And the whole distribution sits at about 0.001 percent of a zodiac sign at the median and under 0.02 percent at the worst single point, nowhere near enough to move a body across a sign, a nakshatra or a Human Design gate boundary, which is the only threshold that changes what a reader sees.

## 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, sample size and span match. RoxyAPI publishes the parts that make an answer possible: 210 positions across 21 charts against NASA JPL Horizons DE441, a 1.5 arcsecond median with the mean, the 95th percentile and the worst body beside it, and an MIT licensed benchmark anyone can re-run against any provider, including us.

**What does arcsecond accuracy mean for an astrology API?**

An arcsecond is one 3,600th of a degree. RoxyAPI reports a median deviation of 1.5 arcseconds, about 0.0004 degrees, from NASA JPL Horizons, which is far finer than the human eye can resolve and about 0.001 percent of a zodiac sign. At that scale a position cannot move a planet into a different sign, nakshatra or house, which is the only difference a reader would ever see.

**How do I verify an astrology API myself?**

Clone the open benchmark at github.com/RoxyAPI/astrology-api-benchmark, run `python3 benchmark.py` against RoxyAPI, then point the same script at any other provider with `--base-url` and `--natal-path`. The repository ships the chart inputs, the NASA JPL Horizons reference values and the runner, so the comparison is yours rather than ours, and adding your own charts is one row plus one regeneration command.

**Is 1 arcsecond good accuracy for planetary positions?**

It is at the resolution floor of the reference rather than meaningfully better than it. NASA JPL Horizons publishes four decimal degrees, roughly 0.36 arcseconds, so any provider claiming a figure below about one arcsecond against it is reporting quantization rather than a measurable advantage. RoxyAPI publishes 1.5 arcseconds as the measured median and states the 0.36 arcsecond floor beside it, so the two are never confused.

**Does a smaller median deviation against NASA JPL Horizons mean a better ephemeris?**

Not on its own. If the engine derives its positions from a compressed fit of a NASA JPL development ephemeris, a very small deviation against JPL is a fidelity figure for that compression rather than an independent check. Roxy Ephemeris derives positions independently, so its 1.5 arcsecond median over 210 positions in 21 real charts is an agreement between two separate derivations.

## Conclusion

An astrology API accuracy claim is only as good as the five things around it, and every one of them is cheap to publish and cheap to check. RoxyAPI publishes all five, plus the repository that reproduces them, alongside 258+ endpoints across 18+ insight domains on one key, Remote MCP for agents, typed SDKs and flat pricing with every domain included. Start with [Roxy Astrology API](/products/astrology-api "Western astrology API with natal charts, horoscopes and transits verified against NASA JPL Horizons"), then re-run the benchmark yourself and hold every provider to the same reading.