Why 6 Arcminutes Can Flip a Vedic Marriage Match

Two matching applications can disagree when they use different birth instants or ayanamsa settings. A Moon position near a boundary can move into a different pada, nakshatra or rashi. These are separate boundaries: a pada-only change alters Navamsa placement, while Nadi classification depends on nakshatra and Bhakoot depends on rashi.

Why 6 arcminutes can flip a Vedic marriage match

A nakshatra spans 13 degrees 20 minutes, or 800 arcminutes. Each of its four padas spans 3 degrees 20 minutes, or 200 arcminutes. A small longitude difference can cross a nearby boundary and change the Navamsa sign. Bhakoot depends on the Moon rashi distance between partners and Nadi on their nakshatra classifications. A change within the same rashi and nakshatra does not change those two koota scores.

Ready to build verified kundli matching? Vedic Astrology API returns Moon longitude, nakshatra, and pada with precision suited for matrimonial matching. See pricing.

How nakshatra padas map to navamsa signs

Pada to navamsa mapping follows a fixed rule per element. For movable signs (Aries, Cancer, Libra, Capricorn) the nine navamsas of the rashi start from the rashi itself. For fixed signs they start from the ninth rashi from the sign; for dual signs from the fifth. Ashlesha is the ninth nakshatra and sits entirely inside Cancer, from 16°40 to 30°00 sidereal. Cancer is movable, so the Cancer navamsas start from Cancer at 0°00. Each navamsa is 3°20 of longitude. The four padas of Ashlesha therefore map to navamsa signs Sagittarius, Capricorn, Aquarius, and Pisces. A Moon at 19°58 Cancer sits in Pada 1, navamsa Sagittarius. A Moon at 20°02 Cancer sits in Pada 2, navamsa Capricorn. The boundary is 4 arcminutes apart.

The two sample Moons are 4 arcminutes apart, sit in the same nakshatra, and produce different Navamsa signs. Dasha balance depends on the actual distance traversed within the nakshatra, not on a Navamsa sign label. A pada-only flip does not change Bhakoot or Nadi.

Where pada drift comes from in your API call

Three independent sources can shift the Moon by enough arcminutes to flip a pada. Knowing each source lets you instrument an API integration so the precision floor is known and bounded.

1. Ayanamsa version. Lahiri and KP Newcomb sit a constant 0.097 degrees apart, and Raman sits about 1.45 degrees below both in 2026. Switching ayanamsa near any pada boundary will flip the pada. Lahiri is the official Indian government ayanamsa and the default in most matrimonial software; Raman is older and places every sidereal longitude about 1.45 degrees ahead of Lahiri; KP Newcomb places them a constant 0.097 degrees ahead. The Moon at 19°55 Cancer sidereal under Lahiri is at 20°02 under KP Newcomb, which is on the other side of the pada boundary.

2. Birth time precision. The Moon moves through roughly 13° of longitude per day, which is 32.5 arcminutes per hour or 0.54 arcminutes per minute of clock time. Recording a birth time as 14:00 when the actual time was 14:11 introduces a 6 arcminute Moon drift. Round to the nearest five minutes and you build in up to 1.4 arcminutes of slop on the Moon alone. The Lagna moves about 1° every 4 minutes, which is 15 arcminutes per minute, so birth time uncertainty hits the Ascendant ten times harder than it hits the Moon.

3. Location precision. Coordinates affect the Lagna and house cusps. For the same UTC birth instant, the geocentric Moon longitude used here does not change with the birth city. Resolve the birthplace and historical timezone correctly so local clock time is converted to the right instant.

How to verify pada output across two API providers

Cross-checking the Moon nakshatra and pada between two independent providers takes four numbers per chart: Moon sidereal longitude in degrees, nakshatra name, pada (1 to 4), and navamsa sign. If all four agree, the matching report is reproducible. If the longitudes agree to within 0.05° but pada or navamsa disagree, one provider is using a different ayanamsa or a different pada-to-navamsa rule. If the longitudes disagree by more than 0.1°, the time inputs or the ayanamsa differ. Build a verification harness that runs ten test charts with Moon positions deliberately placed within 30 arcminutes of pada boundaries, then run the same inputs against both providers. Boundary cases are where disagreements surface; charts with the Moon mid-pada agree across almost any reasonable provider. The RoxyAPI Vedic kundli response returns meta.Moon.longitude (sidereal degrees), meta.Moon.nakshatra.name, meta.Moon.nakshatra.pada, and meta.Moon.rashi. Verification is a four-field comparison.

How to call the nakshatra endpoint correctly

Every Vedic kundli endpoint requires latitude, longitude, and timezone. Never ask users to type coordinates. Call GET /location/search first to geocode the birth city, then feed the result into POST /vedic-astrology/birth-chart. The IANA timezone string from the city result resolves to the DST-correct offset for the birth date on the server. Read more about the 27 lunar mansions in the nakshatras complete guide, and the ayanamsa choices in the Lahiri, Raman, KP comparison. For accuracy methodology and the gold-standard test set, see the methodology page.

# Step 1: geocode the birth city
curl -s "https://roxyapi.com/api/v2/location/search?q=Mumbai" \
  -H "X-API-Key: $ROXY_API_KEY" | jq '.cities[0]'

# Step 2: birth chart with Moon nakshatra and pada
curl -s "https://roxyapi.com/api/v2/vedic-astrology/birth-chart" \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1992-08-15",
    "time": "14:11:00",
    "latitude": 19.0760,
    "longitude": 72.8777,
    "timezone": "Asia/Kolkata"
  }' | jq '.meta.Moon'

import { createRoxy } from '@roxyapi/sdk';

const roxy = createRoxy(process.env.ROXY_API_KEY!);

const { data: city, error: cityError } = await roxy.location.searchCities({ query: { q: 'Mumbai' } });
if (cityError) throw cityError;
const place = city.cities[0];

const { data: chart, error } = await roxy.vedicAstrology.generateBirthChart({
  body: {
    date: '1992-08-15',
    time: '14:11:00',
    latitude: place.latitude,
    longitude: place.longitude,
    timezone: place.timezone,
  },
});
if (error) throw error;

console.log(chart.meta.Moon.nakshatra.name, chart.meta.Moon.nakshatra.pada);

import os

from roxy_sdk import create_roxy

roxy = create_roxy(os.environ["ROXY_API_KEY"])

city = roxy.location.search_cities(q="Mumbai")
place = city["cities"][0]

chart = roxy.vedic_astrology.generate_birth_chart(
    date="1992-08-15",
    time="14:11:00",
    latitude=place["latitude"],
    longitude=place["longitude"],
    timezone=place["timezone"],
)

moon = chart["meta"]["Moon"]
print(moon["nakshatra"]["name"], moon["nakshatra"]["pada"])

For the Gun Milan side of matching, post both partners to POST /vedic-astrology/compatibility. The response returns total, maxScore (36), percentage, isCompatible, the eight koota breakdown entries, plus doshas and doshaCancellations. Bhakoot and Nadi appear in breakdown with their scores and in doshas if uncancelled.

FAQ

What is a nakshatra pada?

A nakshatra pada is one quarter of a nakshatra. Each of the 27 nakshatras spans 13 degrees 20 arcminutes of sidereal longitude and divides into four padas of 3 degrees 20 arcminutes each. Pada determines the Navamsa (D9) sign for any planet at that longitude, which is used for marriage matching, baby naming, and divisional chart analysis.

How accurate does a Vedic kundli need to be for marriage matching?

For Ashtakoota Gun Milan to be reproducible, the Moon longitude needs accuracy to within roughly 1 to 2 arcminutes. That is the precision floor where pada output stays stable across calculation engines. Birth time recorded to the nearest minute and ayanamsa pinned explicitly are the two highest-leverage inputs.

Why do two Vedic astrology APIs return different Gun Milan scores?

Different ayanamsa choices, different pada-to-navamsa rules, or different Moon sign lord tables. Lahiri and KP Newcomb sit 0.097 degrees apart and Raman about 1.45 degrees from both in 2026, either of which can flip pada and navamsa assignments near boundaries. Always pin ayanamsa, time precision, and location source before comparing two reports.

What is a navamsa sign?

The navamsa is the ninth divisional chart (D9) used in Vedic astrology, primarily for marriage and dharma analysis. Each rashi divides into nine equal navamsas of 3 degrees 20 arcminutes. Pada 1 of any nakshatra maps to the first navamsa of its rashi group; pada 2 to the second, and so on, following a fixed rule per element.

Does birth time rounding affect Gun Milan?

Yes. The Moon moves about 0.54 arcminutes per minute of clock time. Rounding birth time to the nearest five or ten minutes adds up to 5.4 arcminutes of Moon position drift. If the Moon sits within that range of a pada boundary, the recorded pada and the calculated pada will disagree. Use the recorded birth time without rounding.

How do I verify Moon pada output across two providers?

Run ten test charts with Moon positions deliberately placed within 30 arcminutes of pada boundaries, then compare four fields per chart: Moon sidereal longitude, nakshatra name, pada (1 to 4), and rashi. Disagreements at the boundary cases reveal the ayanamsa or rule differences between providers.

Conclusion

Pada precision is the difference between a kundli matching report a family can trust and one that contradicts the report on the next app. Pin ayanamsa, capture birth time without rounding, and geocode the birth city before calling the chart endpoint. Build kundli matching with verified pada output via the Vedic Astrology API.