The Short Version
DevDarsha computes horoscopes in the Vedic sidereal zodiac. The first step of every calculation is resolving the ayanamsa — the offset between the tropical and sidereal zodiacs — so that every downstream position is expressed against a consistent reference. The default standard is the Lahiri (Chitrapaksha) ayanamsa, and the house system is whole-sign.
Because these conventions are fixed rather than inferred per request, the same birth input returns the same chart every time. The calculation conventions are stable, and the surface continues to expand.
This is a learning guide, not the API reference. Use it to understand the calculation model and what to check, then use the Horoscope documentation for exact request fields, schemas, and errors.
Ayanamsa First
Sidereal astrology measures planetary positions against the fixed stars rather than the moving equinox. To do that, the calculation needs an ayanamsa value for the moment of birth. DevDarsha resolves this value before placing any planet, so the ayanamsa is an explicit input to the chart, not a side effect.
The active standard is reported back to you in the response metadata as meta.calculation.ayanamsa, for example "Lahiri (Chitrapaksha)", alongside meta.calculation.zodiac ("sidereal") and the house system. Reading these fields lets your product show users exactly which conventions produced a chart.
Inputs That Change the Result
A sidereal chart is sensitive to its inputs. The three that matter most are:
- Date and time of birth: planetary longitudes and the ascendant move continuously, so a small time change can shift house placements.
- Place of birth: the ascendant and house cusps depend on location. The API accepts a city name and resolves its coordinates and timezone.
- Timezone handling: the birth time is interpreted in the local time of the resolved place, then converted internally for the astronomical calculation.
Because of this sensitivity, testing representative births — different times of day, hemispheres, and edge cases near midnight — is the fastest way to build confidence.
What Gets Verified
Chart output is checked against a set of reference cases with known expected values. These regression cases cover ascendant and planetary placement, divisional-chart derivation, and dasha sequencing. When the calculation changes, the reference cases are re-run so that a change in one area does not quietly shift another.
DevDarsha publishes a public Accuracy & Methodology page describing how each area of the platform is verified and which conventions are active. Review it before committing to an integration.
Stability and Versioning
The calculation conventions described here are stable, and the public routes use URI versioning under /v1/.... Newer capabilities may be added over time; when a version is retired it is expected to receive notice, and deprecated responses can carry migration guidance in dev_notes.
What to Check Before You Build
A short pre-integration checklist:
- Confirm the conventions in
meta.calculationmatch what your product expects to display. - Test a handful of representative births in Playground, including tricky birth times.
- Decide how your UI handles plan-gated or optional fields so a missing field never breaks a screen.
- Store the
X-Request-IDfrom responses so a specific chart can be traced when debugging.