Differences from other providers

If you are migrating from another astrology API and the outputs don’t match, the cause is almost never the math — modern providers compute from the same Swiss Ephemeris lineage. It is almost always a default that differs. When defaults differ silently, the resulting support ticket reads “your API is wrong”; this page exists to turn that ticket into a lookup. Every divergence below is inspectable in meta.settings_resolved, which is echoed on every response.

Where defaults diverge

Setting	Astral default	Common elsewhere	Size of the difference
Lunar node	node_type: "true" (true node)	Mean node	Up to about 1°45′
Zodiac	tropical for all /western/* endpoints	Vedic-focused APIs default to sidereal (usually Lahiri)	Roughly 24° on every longitude
Ayanamsa	None — explicit and required with sidereal	Implied Lahiri	From a few arcminutes to over a degree, depending on the pair of ayanamsas
Retrograde	Sign of speed at the queried instant	Varies (some difference daily positions)	Disagreement only within hours of a station

Node: true by default

We default to the true node; many providers default to the mean node. The true node oscillates around the mean node, and the difference between the two can reach about 1°45′. If your node positions differ from a previous provider’s by up to that much while every planet matches exactly, this is the explanation — not an accuracy problem on either side.

To reproduce a mean-node provider’s output, set it explicitly and confirm in the echo:

curl -s https://astral-external-api-iksoi6t3nq-ue.a.run.app/v1/western/positions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": { "datetime": "1990-05-15T14:30:00-04:00" },
    "settings": { "node_type": "mean" }
  }' | jq .meta.settings_resolved

Note that node_type also selects which node appears in the default bodies list (true_node or mean_node), so the body name in the response changes along with the position.

Zodiac: tropical by default, ayanamsa always explicit

All /western/* endpoints default to the tropical zodiac. Providers built for Vedic astrology default to the sidereal zodiac, almost always with the Lahiri ayanamsa — and the two zodiacs currently differ by roughly 24 degrees on every longitude. If every position is off by about 24°, you are comparing zodiacs, not errors.

When you do request sidereal, the ayanamsa is required, never implied: lahiri, raman, and krishnamurti are supported today. This is deliberate — different ayanamsas shift all longitudes by the difference between them, from a few arcminutes to more than a degree, so an implicit choice would be an invisible source of diffs. Requesting sidereal without an ayanamsa is a 422 (settings.ayanamsa.required), not a silent Lahiri.

Retrograde and speed

Positions include speed (degrees per day) and retrograde, where retrograde is simply whether the speed is negative at the queried instant. Providers that instead difference daily positions, or report a whole calendar day as retrograde, can disagree with us for a few hours around a planetary station. Away from stations, everyone agrees.

Upcoming: house systems

Houses have their own default-divergence story, documented ahead of shipping. When house endpoints arrive, our default will be Placidus (the most common default among Western providers, though by no means universal — Whole Sign defaults exist too, and the two produce different house placements for the same chart). whole_sign and equal will be defined at all latitudes, while quadrant systems like Placidus will return a documented error (settings.house_system.undefined_at_latitude) above the polar circles — including the failing latitude and the list of systems that would succeed — rather than silently substituting a different system, which is a behavior you may have encountered elsewhere.

Comparing outputs the reliable way

A few practices make cross-provider diffs quick to close out:

• Pin the settings, don’t trust defaults on either side. Send zodiac, node_type, and (if sidereal) ayanamsa explicitly, mirroring the other provider’s documented configuration, and confirm meta.settings_resolved matches what you sent.
• Compare decimal longitudes, not re-derived degree/minute/second strings. We return both representations precisely so nobody has to write conversion code — conversion and rounding code is where comparison artifacts breed.
• Expect determinism from us. Identical inputs with the same meta.calc_version produce byte-identical outputs, so a cross-provider diff is stable: measure it once and it stays explained. When calc_version changes, the changelog says what moved and why. See Determinism & calc_version.

If, after aligning settings, a discrepancy survives that this page doesn’t explain, we want to know about it — that is either a documentation gap or a bug, and both get fixed. Include the full response meta (it contains everything we need: calc_version, settings_resolved, subject_resolved, and the request_id from any error).