Methodology

Planetary positions are computed from NASA JPL ephemeris data — the full 105 MB data set rather than an abridged one, with 735 fixed stars, covering 500–2999 AD. Nothing is interpolated from a table of pre-computed almanac values, and there is no cached result: every response is calculated for the exact instant and coordinates in the request.

That range matters for two real cases — historical charts, and long-range dasha and transit scans that run decades past the present. A library limited to the modern era silently degrades at the edges.

The largest source of disagreement between two Vedic calculations is not arithmetic, it is the ayanamsa. Indian traditions genuinely differ about it, and a difference of a degree moves a planet across a nakshatra boundary.

So we expose 48 of them — the Surya Siddhanta family, true Citra, true Revati, true Pushya, Raman, KP, Yukteshwar and the rest — and let you correct any by degree, minute and second. We do not ship one and call it correct. If our output disagrees with another source, the first thing to check is whether you are both using the same ayanamsa.

This is the part most API documentation cannot claim. Our reference is not written by hand — it is generated from the serializers themselves by build_api_catalogue, then proved against a running server by verify_api_catalogue, which sends every documented example request and checks it returns 2xx.

The consequence is the thing worth having: every example on every one of the 309 endpoint pages is a real captured response, not an invented one, and a field cannot quietly drift out of the docs the way it does in a hand-maintained spreadsheet. If a serializer changes and the docs are not regenerated, verification fails rather than publishing a lie.

The same catalogue generates the OpenAPI spec, the Postman collection and llms.txt, so all four describe the same API by construction.

The backend carries 1,106 test functions across 43 modules. They cover the metering path most heavily, because that is where a mistake takes someone's money: that a successful call deducts exactly one credit, that a 4xx and a 5xx deduct none, that a concurrent race for the last credit cannot drive a balance negative, and that the ledger reconciles against the balance after a randomised sequence of grants and spends.

We publish 65 ms median and 69% under 100 ms. Those come from calling every one of the 153 published examples once each against the API and recording server-side time — not from timing a fast endpoint and rounding.

Which is why we also say this: a handful of endpoints are much slower, and they are documented as such. A full varshaphal sweep or a year of raasi dasha is seconds, not milliseconds, because it is a scan rather than a lookup. A median hides that; publishing the distribution beside it does not.

median   65 ms      half of endpoints are faster than this
<100ms   69%        the bulk of ordinary lookups
slow     seconds     deep scans — named in the reference

Two things we would like to publish and have not, said plainly rather than left for you to assume:

• An independent positional benchmark. We compute from JPL ephemeris data, but we have not yet published a run comparing our output against JPL Horizons across a spread of dates and bodies, with the deviations and the code to reproduce them. Until we do, take the accuracy claim as “computed from this source” rather than “verified to this tolerance”.
• Published uptime. We do not yet operate a public status page with historical availability. See transparency for what we do commit to.

Both are on the list. Neither is hard; both are work we would rather do properly than approximate.

The playground makes real calls with no account, so you can compare our output against whatever source you already trust before you spend anything. If you find a disagreement we cannot explain by ayanamsa, we want to hear about it.