I found 3 real accuracy bugs in a Vedic astrology API, so I built my own computation layer

The problem

I run a product that depends on Vedic astrology calculations — birth charts, planetary positions, dasha (planetary period) timing. It was calling a third-party API that does roughly $5.7M/year in revenue. Popular, established, trusted by a lot of developers.

While cross-checking their output against Jagannatha Hora — the reference software professional astrologers actually use to verify calculations — I found real, systematic errors in their calculations. Not edge cases. Core math.

The three bugs

1. Wrong divisional chart formula. Divisional charts (D1 through D60) are derived from a planet's exact degree using specific per-chart formulas defined in classical texts (BPHS). The incumbent was applying a single generic formula (degree * N) across all chart types. That's mathematically wrong for most of them — D9 (Navamsa) alone has three completely different starting-point rules depending on whether the sign is movable, fixed, or dual.

2. Broken dasha-cycle loop. Vimshottari Dasha is a 120-year cyclical system split across 9 planetary periods. Their cycle-advancement logic broke after the first full cycle — meaning any dasha calculation past ~40 years into a person's life was computing the wrong planetary lord entirely.

3. Sunrise/sunset approximation error. They were using a Spencer (1971) approximation formula, which has a known error margin of up to 15 minutes, plus a double-timezone-offset bug in a fallback path. I verified this against a real location (Mumbai, a specific date) — the approximation was off by nearly 6 hours in the worst case I found (returning an 11:52 AM "sunrise").

The fix

I rebuilt the whole computation layer locally using Swiss Ephemeris (the open astronomical computation library most serious astrology software is built on), rather than depending on someone else's server for math I could verify and own myself.

• Divisional charts: implemented the actual BPHS-defined formula per chart type (movable/fixed/dual starting points, trikona rules, etc.) — verified 180/180 against JHora
• Dasha cycles: rewrote as a flat, correctly-looping sequence instead of a broken multi-cycle loop
• Sunrise/sunset: switched to Swiss Ephemeris's real swe_rise_trans() calculation, verified against known-correct data

What I learned

The scariest part wasn't finding the bugs — it was realizing how easy they'd be to miss. All three produce plausible-looking output. A wrong divisional chart still shows a real zodiac sign and house number. A broken dasha calculation still shows a real planet name and a real-looking date range. Nothing errors. Nothing looks obviously broken. You only catch it by cross-referencing against independent ground truth, which most people integrating a third-party API never do.

If you're depending on any external API for domain-specific calculations (finance, health, legal, astronomy, whatever), and you've never independently verified its output against a trusted reference: it's worth doing once. You might be surprised.

The API is now live at vedintelastroapi.com — 133 endpoints, 7-day free trial. Happy to answer questions about the accuracy-verification process or the Swiss Ephemeris integration specifically.