The 27 Nakshatras: a developer's API guide

The 27 nakshatras are the lunar mansions of Vedic astrology: each is a fixed 13°20' slice of the ecliptic, and a person's birth nakshatra is simply the one the Moon occupied at the moment of birth. To get it from the Vedika API, send the birth datetime, latitude, longitude, and timezone to /v2/astrology/nakshatra (or read the Moon block from the full chart endpoint); the response returns the nakshatra name, its index from 1 to 27, the pada (1–4), and the Moon's sidereal longitude. This guide covers the underlying math, the endpoint shapes, the pada-to-navamsa mapping, and how interpretation stays source-cited.

What a nakshatra actually is

The zodiac is a 360° circle. The twelve signs divide it into 30° arcs; the 27 nakshatras divide the same circle into equal 13°20' arcs (360 / 27 = 13.333°). Because the two grids are independent, a planet near a sign boundary can sit in a nakshatra that “belongs” to the neighbouring sign — which is exactly why you compute nakshatra from raw longitude, not from the sign.

Each nakshatra also has a ruling planet drawn from the Vimshottari sequence (Ketu, Venus, Sun, Moon, Mars, Rahu, Jupiter, Saturn, Mercury, repeating three times across the 27). That lord is what links the birth nakshatra to the dasha timeline, so the same Moon-longitude lookup that names the star also seeds the 120-year dasha cycle.

The 13°20' boundaries

The pattern is mechanical: nakshatra index = floor(sidereal_longitude / 13.3333) + 1. The remainder within that 13°20' window, divided into four 3°20' quarters, gives the pada.

Sidereal vs tropical: the offset that trips people up

This is the single most common integration bug. Nakshatras are sidereal — measured against the fixed stars. Most Western tools report the tropical Moon, measured from the vernal equinox, which currently differs by roughly 24° because of the precession of the equinoxes. Feed a tropical longitude into a nakshatra lookup and you will land one or two nakshatras off.

The correction is the ayanamsa, the angular gap between the two frames. The Lahiri ayanamsa is the standard for Vedic work and is the default here. Vedika returns Vedic (sidereal), Western (tropical), and KP from one API, so instead of converting by hand you request the frame you need and let the engine apply the right ayanamsa. If you ever see a nakshatra that looks “off by one,” check whether the longitude you fed in was tropical.

The pada: where the real precision lives

Each 13°20' nakshatra is split into four padas of 3°20'. The pada is not cosmetic — it maps the Moon onto a specific navamsa (D9) sign, and the navamsa is the divisional chart classical texts lean on for marriage, dharma, and inner strength. The 108 padas (27 × 4) tile the whole zodiac and line up one-to-one with the 108 navamsa segments, which is why 108 recurs throughout the tradition.

Practically, the pada drives:

• Name-letter (akshara) suggestions — each pada has a traditional starting syllable, used for naming and for some compatibility checks.
• Finer dasha resolution — the balance of the first mahadasha depends on how far through the nakshatra the Moon has travelled, which the pada makes legible.
• Navamsa placement — pada 1 of a fire-sign nakshatra and pada 4 of an earth-sign nakshatra land in very different D9 houses.

Read pada in the response, not just nakshatra. A surprising number of consumer apps drop it and lose most of the system's resolution.

Calling the API

The computation endpoints under /v2/astrology/* take flat fields: datetime, latitude, longitude, timezone. Authentication is a single header, x-api-key: vk_live_*. The base URL is https://api.vedika.io. You can prototype against the free sandbox with no key first.

cURL

curl -X POST https://api.vedika.io/v2/astrology/nakshatra \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "datetime": "1994-11-08T14:30:00",
    "latitude": 18.5204,
    "longitude": 73.8567,
    "timezone": "Asia/Kolkata"
  }'

A representative response shape:

{
  "nakshatra": "Anuradha",
  "index": 17,
  "pada": 2,
  "lord": "Saturn",
  "moonLongitude": 224.83,
  "sign": "Scorpio",
  "ayanamsa": "lahiri",
  "dataSource": "vedika-ephemeris"
}

Node.js

const res = await fetch("https://api.vedika.io/v2/astrology/nakshatra", {
  method: "POST",
  headers: {
    "x-api-key": process.env.VEDIKA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    datetime: "1994-11-08T14:30:00",
    latitude: 18.5204,
    longitude: 73.8567,
    timezone: "Asia/Kolkata",
  }),
});

const { nakshatra, pada, lord, moonLongitude } = await res.json();
console.log(`Moon in ${nakshatra} pada ${pada} (lord ${lord}), ${moonLongitude}\u00B0`);

Python

import os, requests

resp = requests.post(
    "https://api.vedika.io/v2/astrology/nakshatra",
    headers={"x-api-key": os.environ["VEDIKA_API_KEY"]},
    json={
        "datetime": "1994-11-08T14:30:00",
        "latitude": 18.5204,
        "longitude": 73.8567,
        "timezone": "Asia/Kolkata",
    },
    timeout=15,
)
data = resp.json()
print(data["nakshatra"], "pada", data["pada"], "lord", data["lord"])

When you want interpretation, not just the placement

The endpoints above are pure computation — deterministic, cacheable, and the same every time for a given birth moment. When you want a written reading instead, the AI query endpoint takes a natural-language question plus the same birth details:

curl -X POST https://api.vedika.io/api/v1/astrology/query \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "What does my birth nakshatra say about my temperament?",
    "birthDetails": {
      "datetime": "1994-11-08T14:30:00",
      "latitude": 18.5204,
      "longitude": 73.8567,
      "timezone": "Asia/Kolkata"
    },
    "speed": "fast"
  }'

Add "speed": "fast" for a lower-latency path, or stream tokens from /api/v1/astrology/query/stream over SSE for a chat-style UI. The placement that anchors the answer still comes from the computed nakshatra — the language layer never invents the chart.

The ephemeris underneath

Every nakshatra value resolves to a single number: the Moon's sidereal longitude. That number is only as trustworthy as the ephemeris that produces it. Vedika is built on XALEN Ephemeris, our own open-source engine (Apache-2.0, available as crates.io/xalen, PyPI xalen, and @xalen/wasm) with roughly 2,200 tests. Its positions are validated against JPL DE440 and swetest, with no chart deviating beyond 0.1° across a reproducible JPL DE440 benchmark run.

To be precise about what that means: this is astronomical precision — where the Moon was — not a claim about astrological interpretation, which is a separate, tradition-bound layer. But it matters here because a tenth of a degree of Moon error is enough to flip a pada near a 3°20' boundary, and a degree of error can flip the nakshatra itself. Tight ephemeris bounds are what keep boundary cases stable.

Keeping interpretation honest

Nakshatra meanings are a place where it is easy to ship plausible-sounding text with no provenance. Interpretive output here is attributed to the classical texts that real astrologers train from — Brihat Parashara Hora Shastra, Phaladeepika, Saravali, and the KP Readers for Krishnamurti work — rather than to blog summaries or generic paraphrase. For a B2B product surfacing claims to end users, that auditable trail is the difference between a feature and a liability.

Key facts

• There are 27 nakshatras, each spanning 13°20' of the ecliptic; the birth nakshatra is the one the Moon occupied at birth.
• Each nakshatra has 4 padas of 3°20'; 27 × 4 = 108 padas that map one-to-one onto the navamsa (D9).
• Nakshatras are sidereal (Lahiri ayanamsa by default); tropical Moon longitudes will land you on the wrong star.
• The endpoint is POST /v2/astrology/nakshatra with flat datetime, latitude, longitude, timezone; auth via x-api-key: vk_live_*.
• The birth nakshatra's lord seeds the Vimshottari dasha cycle.
• Vedika serves Vedic, Western, and KP from one API, with 700+ operations across 25 domains and 30 languages.
• Positions come from XALEN Ephemeris, validated vs JPL DE440 and swetest within 0.1° astronomically.

Where to go next

Prototype the calls above against the no-key sandbox, then read the full request and response schemas in the docs. If you are weighing this against other providers, the pricing page lays out the plans (Starter at $12/mo through Enterprise at $240/mo, with per-query costs of $0.01–$0.05). For the dasha timeline that the nakshatra lord drives, see our guide on the Vimshottari dasha API.