Pillar A — How it works

Published 2026-05-17 · Updated 2026-06-18 · By Avinash Chandan, Founder, Navamsha

Lahiri vs Raman, KP, and Other Ayanamsas — Which One Should Your App Use?

Ayanamsa is the angular difference between the tropical zodiac (used in Western astrology) and the sidereal zodiac (used in Vedic astrology), subtracted from tropical longitudes to produce Nakshatra, sign, and house positions.

Every Vedic chart calculation depends on which ayanamsa you choose. The same birth time can land the Moon in different Nakshatras under Lahiri, Raman, or Krishnamurti (KP) — which cascades into Dasha timing, Panchang elements, and compatibility scores.

Why ayanamsa matters in production apps

Ayanamsa is not a cosmetic setting. It changes sidereal longitudes for every graha, which changes Nakshatra, pada, Vimshottari starting lord, and Ashtakoot inputs derived from the Moon.

• Dasha APIs: Moon Nakshatra and first Mahadasha balance shift with ayanamsa.
• Panchang APIs: Tithi and Nakshatra boundaries depend on sidereal Moon/Sun separation.
• Compatibility APIs: 36-point Ashtakoot scoring uses Moon-derived koota values.
• Kundali APIs: Lagna degree and whole-sign house assignments move with ayanamsa.

Lahiri (Chitrapaksha) — the Navamsha default

Lahiri ayanamsa is the official standard adopted by the Government of India for the Rashtriya Panchang and is the default in most contemporary Vedic software worldwide.

Navamsha defaults to Lahiri because it maximizes interoperability: your charts align with Jagannath Hora, Parashara's Light, most matrimony portals, and the majority of Indian Panchang publications. Every response includes engine metadata stamping ayanamsa, engine version, and formula version.

Raman ayanamsa

Raman ayanamsa, associated with B.V. Raman, applies a slightly different sidereal offset than Lahiri — typically a fraction of a degree at modern epochs.

That small delta can shift borderline Nakshatra and sign cusps. Some traditional schools prefer Raman for specific interpretive lineages, but it is far less common in mass-market apps than Lahiri.

KP (Krishnamurti) and other variants

Krishnamurti Paddhati uses its own ayanamsa convention tied to the KP sub-lord system. KP practitioners often need exact sub-lord boundaries that differ from Lahiri-driven Parashari charts.

Other historical ayanamsas (Yukteshwar, True Chitrapaksha, custom offsets) exist in niche software. The practical rule for B2B APIs: pick one standard, document it, and expose it in metadata so downstream consumers can reconcile results.

Comparison at a glance

Verifying ayanamsa in API responses

Navamsha returns structured metadata on every calculation: engine name, engine version, ayanamsa, node mode, house system, formula version, and timezone source. This lets you log and replay calculations for support tickets or validation reports.

curl -X POST "https://api.navamsha.in/api/v1/kundali/basic" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "year": 1995, "month": 8, "date": 15, "hours": 14, "minutes": 30, "seconds": 0, "latitude": 19.0760, "longitude": 72.8777, "timezone": 5.5, "settings": { "observation_point": "topocentric", "ayanamsha": "lahiri", "language": "en" } }'

import httpx

payload = {
    "year": 1995, "month": 8, "date": 15,
    "hours": 14, "minutes": 30, "seconds": 0,
    "latitude": 19.0760, "longitude": 72.8777, "timezone": 5.5,
    "settings": {"ayanamsha": "lahiri", "observation_point": "topocentric"},
}
resp = httpx.post(
    "https://api.navamsha.in/api/v1/kundali/basic",
    headers={"X-API-Key": "YOUR_API_KEY"},
    json=payload,
)
chart = resp.json()
print(chart.get("metadata", chart["output"]))

Inspect the metadata block to confirm ayanamsa: lahiri before storing chart snapshots. For chart utilities see /apis/kundali; for Dasha timing that depends on Moon Nakshatra see /apis/dasha. New accounts receive 10,000 free API calls per month — start at /getting-started.