Skip to content
AstroWay/api v2.26.0 · vedic
all systems operational

Vedic FAQ

Collected questions that come up during Vedic integration. If yours isn’t here — email hello@astroway.info, we’ll add it.

Which ayanamsas are supported? Which to choose?

Section titled “Which ayanamsas are supported? Which to choose?”

The API supports 7 ayanamsas:

CodeNameWhen to use
lahiri (default)Chitra-PakshaIndian government standard; the largest mass market. For most Vedic apps — this.
ramanB.V. RamanIf your app targets the South Indian market (Karnataka, Tamil Nadu).
krishnamurtiKPIf calling /v1/vedic/kp/* — KP has its own ayanamsa.
yukteshwarSri YukteshwarDistance from Spica; theosophical / Western-leaning audiences.
fagan-bradleyFagan/BradleyWestern sidereal (not Vedic). For astrologers migrating from sidereal-Western traditions.
de-luceDe LuceOlder astrologers’ choice, rare.
jn-bhasinJN BhasinSpecific school, rare.

The difference between ayanamsas is usually 0.5–1.5° — for most natal charts it does not change the signs, but it affects degree-based techniques (Nakshatra position, Argala, etc.).

Sidereal or tropical? What does the API return?

Section titled “Sidereal or tropical? What does the API return?”

By default, Vedic endpoints return sidereal positions (zodiac fixed to stars, ayanamsa applied). Western endpoints (/v1/chart, /v1/synastry) return tropical (zodiac fixed to the equinox).

For tropical-Vedic (a rare edge case — Sanjay Rath and Ernst Wilhelm propose it) — pass zodiac=tropical to the Vedic endpoint that supports it.

SchoolRegion / AudienceStrength
Parashara (BPHS)All Vedic world — universal baselineMost complete corpus of techniques; always start here
JaiminiTamil Nadu + advanced practitionersKaraka-based predictions; AK-driven life themes
Lal KitabPunjab + North IndiaUnique remedies (upayas), Manglik-specific
KP (Krishnamurti)Tamil Nadu + Andhra PradeshSub-lord theory, precision in event-timing

Pratyangira, AstroSage and other major APIs mostly ship Parashara only. AstroWay covers all four through separate endpoint groups.

AshtakootDashakoota
RegionNorth/Central India, Pakistan, NepalSouth India (Tamil Nadu, Karnataka, Kerala)
Scale36 points max10 koots (factors)
ComponentsVarna + Vashya + Tara + Yoni + Graha Maitri + Gana + Bhakoot + NadiDina + Gana + Mahendra + Stri-Dirga + Yoni + Rashi + Rashi-adhipathi + Vashya + Rajju + Vedha
API/v1/vedic/compatibility/ashtakoot/v1/vedic/compatibility/dashakoota

If your matchmaker serves all of India — call /v1/vedic/compatibility/full — you get both + Manglik + Bhrigu.

Mangal Dosha = Mars in the 1/2/4/7/8/12 house from the Lagna, Moon, or Venus (schools interpret differently). In India — this is a deal-breaker for marriage: if both partners have a Mangal affliction without compensation, a traditional astrologer won’t green-light without upayas (remedies) or compensating factors.

API endpoint: /v1/vedic/compatibility/manglik-check — returns { chart1: { manglik: true/false, severity, factors }, chart2: ..., compensation: ... }.

D9 (Navamsha) — why is it the most important varga?

Section titled “D9 (Navamsha) — why is it the most important varga?”

D9 = 9-fold division of each sign = detailed “soul-level” chart. In Vedic — used for:

  1. Marriage predictions — Venus + 7th lord in D9 show the true nature of married life
  2. Strength of planets — a planet strong in D1 but weak in D9 = “shows but doesn’t deliver”
  3. Vargottama — a planet in the same sign in D1 and D9 = special strength

API: /v1/vedic/vargas returns all 16 divisions in a single call; focus on D9 for marriage/relationship features.

Why is birth time critical? What to do if unknown?

Section titled “Why is birth time critical? What to do if unknown?”

Vedic is highly time-sensitive:

  • The Lagna (Ascendant) changes every ~2 hours — that shifts the WHOLE chart
  • Moon Nakshatra changes every 6–8 hours
  • Dasha balance (initial period) depends on the Moon’s nakshatra position

If the exact time is unknown:

  1. Sunrise chart — use 06:00 local time as an approximation. The Lagna will be Aries/Taurus for a Leo/Capricorn Sun; some Vedic astrologers consider sunrise charts valid for general-tendency forecasting
  2. Rectification — call /v1/rectification with 2-3 known life events (marriage, child, job switch) — the API returns a probable birth-time window
  3. Disclaimer to the user — tell them results with unknown time are an approximation, not an exact chart

Vedic traditionally uses Whole Sign houses (the entire sign = one house). Western — Placidus / Koch / Equal etc.

AstroWay’s default for Vedic = Whole Sign. For KP endpoints — Placidus (KP convention). Pass the houseSystem parameter if you need a different one: whole-sign, placidus, koch, equal, porphyry.

Yes — and it’s even recommended for multi-tradition audiences. Architecture:

  1. The natal chart is computed once — Western and Vedic endpoints share the same input (date/time/lat/lon)
  2. Expose a “Western view” / “Vedic view” toggle in your UI
  3. Vedic Moon sign (rashi) is often confused with the Western Sun sign — warn the user about the difference
  4. Compatibility — you can show BOTH: Western synastry + Vedic Ashtakoot simultaneously

The /v1/compat/astro-vedic endpoint does this automatically — Western synastry × Vedic Ashtakoot bridge.

What ephemeris is used? How accurate is it?

Section titled “What ephemeris is used? How accurate is it?”

Swiss Ephemeris (LGPL) — the same engine used by Solar Fire, Kepler, Astro Gold, Janus, AstroSeek. Accuracy:

  • Planetary positions: ±1 arc-second vs NASA JPL ephemeris
  • House cusps: ±1 arc-minute
  • Ayanamsa: Lahiri-table cross-validated against official Indian government tables

For Vedic-specific calculations (Nakshatra-position, Vimshottari balance, Vargas) — cross-checked against PyJHora (de-facto Python reference); divergences < 0.01° where present. Divergence report — docs/AUDIT-TRAIL.md in the repo.

Yes — most Vedic endpoints are deterministic for the same chart input. Stable cache key: hash(date + time + lat + lon + ayanamsa + endpoint).

The API also offers an X-Idempotency-Key header — a 5-minute cache on the api-calc side. On a cache hit, credits are not charged.

Vedic endpoints that return interpretations (yoga descriptions, dosha meanings, muhurat reasons) accept the lang parameter. Supported: 21 languages (T0 — uk/en/de/ru manual; T1 — pl/es/pt/hi/fr/ko AI Beta; T2/T3 — planned). Details: /en/languages/.

If an endpoint returns numeric data (degrees, dates, sign indices) — those are language-neutral. Text fields (note, meaning, manifestation) — localized.

YELLOW = the endpoint works, but has one of three characteristics:

  1. Single-author school (Lal Kitab, KP) — no cross-verification with other schools because they don’t exist
  2. Scoring / heuristic-based (compatibility 0-100, breakup-timing) — numeric score subjective by nature
  3. Intrinsic precision limit (rectification, Bhrigu match) — the algorithm has an inherent precision floor

See docs/AUDIT-TRAIL.md for a specific endpoint — it states why YELLOW and whether there’s a path to GREEN. For most — no (intrinsic), and that’s an honest disclaimer for integrators.

Was this helpful?
Suggest an edit

Last updated: