Why Two Kundlis Never Match Across APIs: A Debugging Guide

About the author: Brajesh Vashisht is a Vedic Astrologer and KP Systems Specialist with over 22 years of experience in Vedic astrology and Krishnamurti Paddhati. He consults on matrimonial matching, career timing, and muhurta selection for clients across India and internationally. His research focuses on precision event timing using dasha systems, ashtakavarga scoring, and Vedic divisional charts, and he is currently writing a long-form guide to KP sub-lord theory and nakshatra analysis.

You enter the same birth date, time, and city into two different Vedic API integrations. One places the Moon in Rohini nakshatra, the other in Mrigashira. One gives Mercury a sub-lord of Venus; the other says Jupiter. You check the request bodies: they look identical. The birth data is correct. So why are the charts different?

This is not a data quality problem. It is a parameter agreement problem. Every Vedic calculation has at least five independent configuration axes, and most APIs default each one silently. When two providers choose different defaults, charts that look like they share birth data actually do not share the same coordinate system. This guide names each axis, quantifies the magnitude of the divergence it produces, and gives you a debug recipe to resolve any mismatch in under ten minutes.

The five reasons two kundli APIs give different results

The table below maps each cause to its typical magnitude, what it breaks in the output, and the API parameter you set to lock it down.

Ready to build this? Vedic Astrology API gives you explicit control over all five axes in a single key. See pricing.

Ayanamsa: the biggest source of divergence

Ayanamsa is the angular correction subtracted from a tropical planetary longitude to produce the sidereal longitude used in Vedic and KP astrology. Every Vedic API must apply one. The disagreement between providers often comes from choosing different ayanamsa systems without making that choice visible in the response.

That 0.097-degree gap between Lahiri (Chitrapaksha) and KP-Newcomb is not a rounding error: it is enough to shift a planet sitting near a nakshatra boundary into the adjacent nakshatra, changing the dasha lord assignment and every subsequent period date by months. Lahiri is the Government of India standard and is used in most traditional Jyotish software. KP-Newcomb is a dynamic formula used by Krishnamurti Paddhati practitioners. The older KP-Old value, derived from Krishnamurti original tables, differs from KP-Newcomb by a further few arc-minutes that widen over time. If one API defaults to Lahiri and another defaults to KP-Newcomb, every planet longitude in the response will differ, even for an identical birth moment.

The worked example below shows the same birth data requested twice, once with ayanamsa: "lahiri" and once with ayanamsa: "kp-newcomb", so you can see the planet longitude difference directly.

# Step 1: resolve birth city to coordinates
curl -s "https://roxyapi.com/api/v2/location/search?q=Delhi" \
  -H "X-API-Key: $ROXY_API_KEY"

# Step 2: KP planets with Lahiri ayanamsa
curl -s https://roxyapi.com/api/v2/vedic-astrology/kp/planets \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1990-07-04",
    "time": "10:12:00",
    "latitude": 28.6139,
    "longitude": 77.2090,
    "timezone": "Asia/Kolkata",
    "ayanamsa": "lahiri",
    "nodeType": "true-node"
  }'
# Returns: ayanamsa: 23.68491... planets[Sun].longitude: 108.3401

# Step 1: resolve birth city (same as above)

# Step 2: KP planets with KP-Newcomb ayanamsa
curl -s https://roxyapi.com/api/v2/vedic-astrology/kp/planets \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1990-07-04",
    "time": "10:12:00",
    "latitude": 28.6139,
    "longitude": 77.2090,
    "timezone": "Asia/Kolkata",
    "ayanamsa": "kp-newcomb",
    "nodeType": "true-node"
  }'
# Returns: ayanamsa: 23.58791... planets[Sun].longitude: 108.4371
# Difference per planet: ~0.097 degrees (Lahiri - KP-Newcomb offset for 1990)

True node vs mean node: the sub-lord flip

The lunar nodes Rahu and Ketu do not orbit in a perfectly uniform arc. The true node follows the actual instantaneous geometry of the Moon orbit ellipse, oscillating back and forth by about 1.5 degrees around the mean node, which is a smoothed average position. The difference between the two calculations peaks near 1.5 degrees and averages around 0.5 to 0.8 degrees for a typical birth chart.

In traditional Jyotish, the distinction is a matter of school preference. In KP astrology, it is consequential. KP sub-lord divisions are 40 arc-minutes wide on average, and a 1.5-degree shift in node position can move Rahu or Ketu across two or three sub-lord boundaries, changing the sub-lord assignment entirely. This means the significator set for any house that Rahu or Ketu occupy changes, which can reverse a KP prediction.

The POST /vedic-astrology/kp/planets endpoint accepts nodeType: "true-node" or nodeType: "mean-node". Set it explicitly. If you are matching charts against a reference tool that uses mean node by default, pass "mean-node". If you are doing event prediction with KP horary where the instantaneous sky matters, use "true-node". The default in most Vedic APIs is "mean-node"; reference tools differ.

House system: Whole Sign vs Placidus cusps

House system choice determines which zodiac degree marks the beginning of each house. Whole Sign assigns the cusp of every house at 0 degrees of the sign that occupies that house, regardless of the birth time. Placidus computes time-based cusps that vary per minute of birth time and per degree of latitude. For an ascendant at 15 degrees of Taurus, Whole Sign places the 2nd house cusp at 0 degrees of Gemini and the 11th house cusp at 0 degrees of Pisces. Placidus places those same cusps at different longitudes depending on the exact birth time and geographic latitude.

The practical consequence: a planet at, say, 28 degrees of Taurus lands in the 1st house under Whole Sign (because all of Taurus is the 1st house) but may be in the 2nd house under Placidus if the Placidus 2nd-house cusp falls at 20 degrees of Taurus. That house assignment change propagates into every house-based interpretation, dasha timing, and KP significator list. Traditional Jyotish practitioners most commonly use Whole Sign. KP astrology is defined by Placidus cusps and does not support substitution. For the standard Vedic birth chart endpoint, the houseSystem parameter accepts "whole-sign" or "placidus" (among others). Knowing which system each API uses by default is a prerequisite for a valid comparison.

Time precision and timezone: how a missing second moves the ascendant

The ascendant, or lagna, moves through approximately 1 degree every 4 minutes, which works out to roughly 0.25 degrees per minute or about 1 arc-minute per 4 seconds of clock time. Feeding an API a birth time of 10:12 instead of 10:12:35 introduces a 35-second gap. At the lagna motion rate, that gap represents approximately 0.15 degrees of ascendant longitude, which is enough to change the KP cusp sub-lord for a chart where a cusp falls near a sub-lord boundary.

The time field on both the birth chart and KP endpoints requires HH:MM:SS format, not HH:MM. Always pass seconds. If the recorded birth time genuinely lacks second-level precision, the correct approach is to note the uncertainty in your application rather than silently truncating to HH:MM:00.

Timezone is the second part of this problem. Both the POST /vedic-astrology/birth-chart and KP endpoints accept timezone as either a decimal offset (5.5 for IST) or an IANA identifier ("Asia/Kolkata"). IANA strings resolve server-side to the DST-correct offset for the birth date: a 1985 New York birth in January gets EST (-5), a July birth gets EDT (-4). If you pass a summer-resolved decimal offset for a winter birth, the chart shifts by exactly 1 hour, moving the ascendant by roughly 15 degrees, which is a completely different lagna. For NRI births outside IST, always pass the IANA string. Feed cities[0].timezone from the location search response directly into the chart request rather than converting to a decimal manually.

How to debug a kundli mismatch in under 10 minutes

The following steps resolve almost every kundli divergence between two APIs. Work through them in order: each step narrows the remaining surface area.

1. Confirm the raw birth data matches. Check date (YYYY-MM-DD), time (HH:MM:SS), latitude, and longitude digit-for-digit in both requests. A rounding difference of 0.01 degrees in latitude shifts house cusps by a small but non-trivial amount at mid-latitudes.
2. Diff the echoed ayanamsa value. A well-designed API echoes the numeric ayanamsa in degrees in the response meta. If both APIs echo this field, subtract the two values. A difference larger than 0.001 degrees means the ayanamsa systems differ. Identify which system each uses and align them.
3. Check the node calculation method. If the Rahu or Ketu longitude differs by more than 0.1 degrees between the two responses, the node type is different. Set nodeType explicitly to the same value in both calls.
4. Verify the house system. If planet house assignments disagree but planet longitudes match, the house system differs. Identify the default in each API and standardize.
5. Check for seconds truncation. If the ascendant longitude differs by less than 0.25 degrees per minute of birth time difference, seconds truncation is the cause. Pass HH:MM:SS explicitly.
6. Check timezone. If everything else matches but the ascendant is off by a large amount (1 full sign or close to it), an IST default was applied to a non-IST birth. Pass the IANA timezone string from the location search response.

Explicit parameters beat defaults every time

Every axis of divergence described above is controllable. The root cause of kundli mismatches is not inaccuracy in the underlying ephemeris: it is implicit parameter agreement. Two APIs produce the same chart if and only if they use the same ayanamsa value, the same node calculation method, the same house system, the same time representation to the second, and the same DST-correct timezone offset for the birth date. If any one of those five is implicit, the chart cannot be reliably compared.

The practical discipline is simple: set all five parameters explicitly on every request, verify they are echoed in the response meta, and diff the meta blocks before comparing planet positions. The POST /vedic-astrology/kp/chart response echoes meta.ayanamsa, meta.ayanamsaType, and meta.houseSystem for exactly this reason.

Frequently Asked Questions

Q: Why is my kundli different on two different apps? A: The most common reason is that the two apps use different ayanamsa systems. Lahiri (Chitrapaksha) and KP-Newcomb differ by approximately 0.097 degrees today, which shifts every planet longitude and can change nakshatra, pada, and sub-lord assignments. Differences in house system (Whole Sign vs Placidus), node calculation method (true vs mean), and timezone handling account for most remaining divergences.

Q: What is the difference between Lahiri and KP-Newcomb ayanamsa? A: Lahiri uses the Chitrapaksha ayanamsa adopted as the Indian national standard in 1956, derived from the position of the star Chitra (Spica) at the vernal equinox. KP-Newcomb applies a dynamic precession formula developed by S.P. Krishnamurti using Newcomb precessional constants, producing a value approximately 0.09 to 0.10 degrees smaller than Lahiri for charts calculated in the 2020s. The gap widens slightly each decade due to the different precession rates used in each formula.

Q: Is KP astrology more accurate than traditional Jyotish? A: The two systems answer different questions. Traditional Jyotish (Parashari) is optimized for character analysis, life theme interpretation, and broad timing via mahadasha periods. KP astrology, using Placidus cusps and the 249-sublord table, is optimized for precise event timing and yes/no horary questions. Accuracy in each system depends on using the correct parameters for that system: KP requires Placidus cusps and KP-Newcomb ayanamsa, and Parashari typically uses Whole Sign or Porphyry with Lahiri ayanamsa. Mixing parameters across systems produces meaningless output, not a more accurate chart.

Q: How do I know which ayanamsa my Vedic API is using? A: Look for an echoed ayanamsa or ayanamsaType field in the response metadata. If the API does not echo this information, you cannot verify which system was applied, which makes cross-API chart comparison unreliable. Pass the ayanamsa parameter explicitly in every request and confirm the numeric value echoed in the response matches your expectation.

Q: Does birth time precision really matter that much for kundli accuracy? A: Yes, particularly for house cusps and the ascendant. The ascendant moves approximately 1 degree every 4 minutes. A 10-minute birth time uncertainty produces a potential ascendant error of 2.5 degrees, which is large enough to change the Placidus cusp sub-lord assignment in KP astrology and to shift a planet across a house boundary in any system. Always pass time as HH:MM:SS. If second-level precision is unavailable for the recorded birth, surface that uncertainty in your application rather than truncating to HH:MM:00.

When two kundlis disagree, the answer is almost never a flawed ephemeris. It is almost always a mismatch on one of the five configuration axes described here: ayanamsa, node type, house system, time precision, or timezone. Set each explicitly, verify them in the response meta, and the charts will converge. See the full endpoint reference on the Vedic Astrology API product page.