Moving from another astrology API

Two astrology APIs can both be correct and still disagree, because each chooses an ayanamsa, a house system, a sunrise and a matching table. Most differences you will see after a move come from those choices, not from errors. Check them first, then compare the results side by side with a test key, which is never charged.

1. Settle the conventions

engine_version

2026.10.10

ayanamsa

lahiri

kp_ayanamsa

kp_new (Lahiri − 5′24″)

house_system

whole_sign

node

true

sunrise

upper limb, refracted

moonrise

the Moon's centre on the true horizon (festival moments; the panchang does not give moonrise)

lunar_month

amanta (new moon to new moon); purnimanta names alongside

ayanamsa_options

lahiri (default), raman, krishnamurti, yukteshwar, fagan_bradley: options.ayanamsa on chart operations; the calendar, panchang and KP are unaffected

not_computed

moonrise in the panchang, yoga/karana end times, Vaishnava paran (Ekadashi), Vaishnava Janmashtami, Ghatak Chakra, Chara-dasha antardashas

The conventions page explains each one. The ones that most often explain a difference:

• Ayanamsa. Ours is Lahiri by default. If your old API used another, pass options.ayanamsa on chart operations (raman, krishnamurti, yukteshwar or fagan_bradley) to match it while you compare.
• Houses. Ours are whole-sign houses from the lagna. An API using Sripati or Placidus houses for Vedic charts will place some planets in a different house; our POST /v1/kundli/bhav-chalit (1 credit) gives the Sripati bhavas.
• Node. Ours is the true node. A mean node differs from it by up to about 1.7°.
• Sunrise. Ours is the upper limb of the Sun, with refraction. A centre-of-disc sunrise is a few minutes later, which can change the vara, Rahu Kaal and choghadiya near their edges.

2. Send the birth the same way

• Time and place. Send the local birth time and the place. We work out the timezone in force at that date, including India's offsets before 1947 (see historical timezones). If your old API took a fixed offset such as +05:30, an older birth can move by an hour; send timezone to match it while you compare. See birth input.
• An unknown time. Old APIs often fill in noon. We do not: set time_accuracy to unknown and the fields that depend on it are left out and listed in warnings.

3. Map the operations

Look up each call you make today in the reference or in the glossary, which names the operation for each term. Several chart calls can be made at once with POST /v1/kundli/bundle (3 credits).

4. Compare side by side

1. Pick some made-up births that cover your users: different decades, places and times of day.
2. Call both APIs, and ours with a test key.
3. Compare the planets' longitudes first. They should agree closely once the ayanamsa and node match; see accuracy for ours against NASA JPL Horizons.
4. Then compare what is built on them: houses, nakshatras, dasha dates, matching scores. A difference there usually traces back to a convention above.

Kundli matching scores

Ashtakoot tables differ between published sources, so two APIs can give different totals for the same couple. Ours uses one published table for each koota, named on conventions, so a score can be checked by hand.

When you are ready

Switch your server to a live key (al_live_). Nothing else changes: the same calls, the same results. If you find a difference you cannot explain, write to us at developers@astrologics.in with the request_id and the input.