Guides

Ayanamsha, house systems, and why charts differ

Two apps can compute a chart for the same birth details and disagree. One shows a different moon sign, a different ascendant, or a different house layout. Neither app is wrong.

Both apps look at the same sky through different reference points. This guide explains what those reference points are. Every explanation uses only what the API demonstrably returns.

Same sky, different reference point

A planet's position is a single physical fact: an angle along the ecliptic. What changes is the zero point you measure that angle from.

The tropical zodiac, used by Western astrology, fixes its zero point to the March equinox. That equinox is the moment the Sun crosses the celestial equator each year.

The sidereal zodiac, used by Vedic astrology, fixes its zero point to the visible background of fixed stars instead. A slow wobble in Earth's axis, called precession, drifts these two zero points apart over centuries.

The angle between the two zero points, at any given time, is the ayanamsha. Subtract the ayanamsha from a tropical position to get the sidereal position for the same planet at the same moment.

That subtraction is the entire mechanism behind the disagreement. A Western app and a Vedic app place the same planet in different signs.

Why two apps show different signs for the same birth

Even within sidereal astrology, more than one convention exists for exactly how large the ayanamsha is. The ayanamsha endpoint computes six of those conventions for the same birth data.

The table below shows what the ayanamsha endpoint returns for one sample birth (10 May 1990, 19:55, lat 19.2056, lon 25.2056, tzone 5.5):

POST https://json.astrologyapi.com/v1/ayanamsha

{
  "day": 10,
  "month": 5,
  "year": 1990,
  "hour": 19,
  "min": 55,
  "lat": 19.2056,
  "lon": 25.2056,
  "tzone": 5.5
}

Response:
[
  { "type": "LAHIRI", "degree": 24.101234311094515, "formatted": "24:06:04" },
  { "type": "KP", "degree": 24.00465040376008, "formatted": "24:00:16" },
  { "type": "YUKTESHWAR", "degree": 22.72298340376011, "formatted": "22:43:22" },
  { "type": "RAMAN", "degree": 22.65520140376009, "formatted": "22:39:18" },
  { "type": "JN_BHASIN", "degree": 23.006317403760136, "formatted": "23:00:22" },
  { "type": "FAGAN_BRADLEY", "degree": 24.984592033135584, "formatted": "24:59:04" }
]

These six values, for the same instant, span about 2.33 degrees: from 22.6552° (Raman) up to 24.9846° (Fagan-Bradley). That span is small next to a 30 degree sign. The span is still not zero.

A planet can sit within that 2.33 degree band, measured from a sign boundary in the tropical zodiac. Such a planet lands in different sidereal signs depending on which ayanamsha subtracts it.

For example, take a planet at 23.5° into its tropical sign. Under Lahiri the position falls at 23.5 minus 24.10, which wraps to the previous sidereal sign.

Under Raman the position falls at 23.5 minus 22.66, which stays just inside the current sign. The same physical planet lands in two different sidereal signs, purely because of which ayanamsha was applied.

Sidereal and tropical positions in the API's own responses

planets returns sidereal positions, the Vedic convention. Each entry carries a sign, signLord, and a nakshatra with its own nakshatraLord and nakshatra_pad, fields that only make sense in the sidereal frame.

POST https://json.astrologyapi.com/v1/planets
(same 8 birth fields as above)

Response (Sun, abbreviated):
{
  "id": 0,
  "name": "Sun",
  "fullDegree": 72.18954079246434,
  "normDegree": 12.189540792464342,
  "sign": "Gemini",
  "signLord": "Mercury",
  "nakshatra": "Ardra",
  "nakshatraLord": "Rahu",
  "nakshatra_pad": 2,
  "house": 9,
  "isRetro": "false"
}

planets/tropical returns tropical positions, the Western convention, for the Sun, Moon, the visible planets, Uranus, Neptune, Pluto, and the Ascendant. There is no nakshatra field, because nakshatras are a sidereal concept.

POST https://json.astrologyapi.com/v1/planets/tropical
(same 8 birth fields, plus house_type)

Response (Sun, from the endpoint's own documented sample):
{
  "name": "Sun",
  "fullDegree": 259.3692854715937,
  "normDegree": 19.369285471593685,
  "sign": "Sagittarius",
  "house": 11,
  "isRetro": "false"
}

The two samples above come from each endpoint's own documented example. The two samples are not one shared live computation for a single instant.

The docs panel shows a stored sample response per endpoint. Do not expect these two particular numbers to convert into each other with a simple subtraction.

The samples do show the shape of the difference correctly. The sidereal response carries sign, sign lord, and nakshatra. The tropical response carries sign and house, with no nakshatra at all.

Which endpoint exposes what

Neither planets nor kp_planets exposes a parameter to choose which ayanamsha the endpoint applies.

Each endpoint applies its internal system the same way on every call. Results stay internally consistent, even though the request body never names the system.

Houses: dividing the chart into twelve pieces

Once you have the ascendant, the ecliptic still has to be cut into twelve houses. More than one way exists to make that cut.

house_cusps/tropical takes the same eight birth fields as every other endpoint here, plus a house_type parameter. The documentation gives house_type a default of placidus, with alternatives koch, topocentric, poryphry, equal_house, and whole_sign.

The endpoint returns each house's sign and degree, plus the ascendant, midheaven, and vertex.

POST https://json.astrologyapi.com/v1/house_cusps/tropical
(same 8 birth fields, plus house_type)

Response (abbreviated):
{
  "houses": [
    { "house": 1, "sign": "Cancer", "degree": 114.19653 },
    { "house": 2, "sign": "Leo", "degree": 141.2691 }
  ],
  "ascendant": 138.21237548900893,
  "midheaven": 47.54697697669932,
  "vertex": 235.92360650178892
}

The exact list of accepted house_type values is not identical across every endpoint that takes one. western_horoscope's own documentation lists a longer set, including sripati, horizontal, and campanus.

Check the parameter description on the specific endpoint you are calling. Do not assume one list applies everywhere.

Pick one system, name it, stay consistent

None of these systems is more correct than another in an absolute sense. Inconsistency is what breaks user trust.

A user sees a moon sign computed one way today and a different sign next month, because your app quietly switched endpoints or ayanamsha systems.

Pick one zodiac, and for Vedic content, one ayanamsha. Name the chosen system somewhere in your product (even a small label helps). Keep every chart for every user on that same system.

A user may compare your app to another one and see a different sign. A stated system is the difference between a known convention and an unexplained bug.

Auditing what was applied

birth_details is a minimal endpoint. The response echoes back the inputs and basic solar facts for a birth.

One field matters most here. The response includes the single ayanamsha value that the endpoint actually applied. That value lets you audit a stored chart against the system you believe your app used.

Where to go next

• Astrology terms and API fields for definitions of nakshatra, house systems, and the KP system.
• Timezones, DST, and historical birth data since a wrong tzone shifts every position this guide discusses.
• Ground an LLM on computed charts so an LLM explains a chart using the system you picked instead of guessing at one.