Vedic vs Western Astrology: What Changes in the Code

Adding Vedic charts to a Western astrology app changes six things in your code. The zodiac moves, so most points slide back one sign. Houses become whole signs, with no cusps. The planet list changes. The Moon sign and its nakshatra (birth star) take the lead from the Sun sign. And two new kinds of data arrive: dasha timelines and divisional charts.

Here is what that looks like for one real person. John Doe was born on Aug 15, 1990, at 10:30 AM in New York. A Western chart puts his Sun in Leo. A Vedic chart puts it in Cancer. Of his 10 chart points, 9 move back one sign. His Jupiter keeps its sign but still lands in a different house.

Our API is Vedic only. It returns sidereal positions and has no Western (tropical) mode. So every Western number in this post is our own math. It is the Vedic position plus the gap between the two zodiacs, from the same API answer. We show that math in the open, so you can repeat it.

Below, each change comes with John's real numbers from our API, run on Oct 13, 2026.

Change 1: The zodiac starts about 24 degrees earlier

A Western chart is built on the tropical zodiac. It pins Aries to the March equinox, so the signs follow the seasons. A Vedic chart is built on the sidereal zodiac. It pins the signs to the fixed stars. The Earth's axis wobbles slowly, so the two drift apart a little every year.

The gap between them is the ayanamsa. Our API uses the Lahiri ayanamsa unless you ask for another. On John's birthday it was 23.726073°. On Oct 27, 2026, it is 24.231766°. That is a drift of 50.29 arc seconds a year between the two dates.

Each sign is 30° wide. So any point in the first 23.73° of a Western sign falls in the sign before it in a Vedic chart. For a 1990 birth, that is 79.1% of every sign. Which ayanamsa to pick is a separate choice, covered in Lahiri, KP or Raman ayanamsa.

The code change is one line. Every answer carries the ayanamsa it used in meta.ayanamsa_value. To get the Western longitude, add it and wrap at 360:

// Vedic (sidereal) longitude from the API, plus the ayanamsa from the same answer.
const westernLongitude = (vedicLongitude + meta.ayanamsa_value) % 360;
const westernSign = Math.floor(westernLongitude / 30) + 1; // 1 = Aries, 12 = Pisces

Use the ayanamsa from the same answer, not a fixed number. It changes with the birth date.

John Doe's chart in both zodiacs

The Vedic column is what POST /v1/planets returned for John. The Western column adds 23.726073° to each longitude.

The ascendant is the rising sign, the sign coming up in the east at birth. Jupiter is the only point that stays. It sits at 5.69° of Cancer, and 5.69 + 23.73 is still under 30.

Neither column is wrong. Both describe the same sky, measured from two different starting points. The Vedic vs Western docs page suggests how to explain this to users, so a changed sign does not look like a bug.

Change 2: Houses are whole signs

A house is one of 12 parts of the chart, each tied to an area of life. A Western app may use a cusp system, such as Placidus. There, each house starts at an exact degree, and the houses differ in size.

Our API uses whole sign houses. The rising sign is house 1 in full, the next sign is house 2, and so on. Every reading uses these houses, as rule CH-06 states. The house number comes straight from two sign numbers:

// Rule CH-06: signs are numbered 1 (Aries) to 12 (Pisces).
const house = ((planetSign - ascendantSign + 12) % 12) + 1;

The one exception is the KP endpoint, POST /v1/kp. It uses Placidus cusps, under rule KP-04.

A planet can keep its sign and still change house. John's Vedic ascendant is Virgo, and his Jupiter in Cancer sits in house 11. In the Western zodiac his ascendant moves to Libra, but Jupiter stays in Cancer. Count with the same whole sign rule and Jupiter lands in house 10. The other eight planets move one sign with the ascendant, so they keep their houses.

Aspects change in the same way. A Vedic aspect, or drishti, is a planet's influence on another house. Rule AS-01 counts it in whole houses, with no orb (allowed margin in degrees). Every planet aspects the 7th house from itself. Mars also aspects the 4th and 8th, Jupiter the 5th and 9th, and Saturn the 3rd and 10th. If your code tests angles between planets, it needs a house count instead.

Change 3: Nine planets, no outer planets

A Vedic chart uses nine grahas (planets): the Sun, the Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu and Ketu. Uranus, Neptune and Pluto are not used, as rule CH-11 states.

Rahu and Ketu are not bodies. They are the two points where the Moon's path crosses the Sun's path, always exactly opposite. For John, Rahu is at Capricorn 13.51° and Ketu at Cancer 13.51°. The API returns the true position by default. Send "node": "mean" for the averaged one.

So your planet list changes. Drop three names, add two, and be ready for two points that always move together.

Change 4: The Moon sign leads, and it brings a nakshatra

If your Western app leads with the Sun sign, the Vedic version leads with the Moon sign. That is the sign the Moon was in at birth, also called the rashi. John's Moon sign is Taurus. A Western chart would say Gemini.

The Moon sign drives much of the app. Rule TR-01 counts transits (where the planets are on a given day) from the birth Moon's sign. Our daily reading for a sign, GET /v1/rashi/{sign}/today, takes a Moon sign. Its own reference says it is not a Sun-sign horoscope. Kundli matching also compares the two people's Moons.

The Moon also brings data a Western app has no field for. A nakshatra is one of 27 equal star groups of 13°20′ each. A pada is one of its four quarters. John's Moon is in Mrigashira, pada 1, and Mrigashira's ruler is Mars. The API returns nakshatra, nakshatra_lord and pada for the ascendant and for every planet.

Nakshatras are counted in the sidereal zodiac. So you cannot take them from a Western longitude without the ayanamsa.

Change 5: A dasha timeline

A dasha is a planetary period. The Vimshottari system splits a 120-year cycle into nine periods, each ruled by one planet. The ruler of the Moon's nakshatra runs the first period, as rule DA-02 states.

For John, Mrigashira is ruled by Mars, so his timeline starts with Mars. He had 6.348115 years of it left at birth. Then the periods run in a fixed order:

Mars starts before his birth because the API lists the first period at full length and marks the part already used.

This is new data, not a new sign. Your data model needs a timeline: periods with a start and an end, nested up to five levels deep. The full math is in How Vimshottari Dasha Is Calculated.

Change 6: Divisional charts have signs but no degrees

A divisional chart, or varga, cuts each sign into smaller parts and gives each part a sign. That makes a new chart for one area of life. Rule VG-01 lists the 16 that the API works out, from D1 to D60. D1 is the main birth chart.

POST /v1/chart/D9 returns the navamsa, which the API links to the spouse and to the inner strength of every planet. For John, the D9 ascendant is Gemini, the Sun is in Pisces and the Moon is in Leo.

Each point has a sign and a house, but no degree. If your chart drawing places planets by degree, it needs a sign-only mode for these charts. The D9 and D10 math is in Navamsa (D9) and D10 charts.

To see a full Vedic chart before you write any code, enter a birth in our free kundli tool. For the fields the chart API returns, see the kundli and birth chart API.

What stays the same

Some things do not move at all. Your birth form keeps the same fields: date, local time, latitude, longitude and a time zone name such as America/New_York. The API reads daylight saving from that zone, so John's 10:30 AM was read as UTC-4.

Some Vedic values do not depend on the zodiac either. The tithi, or lunar day, counts how far the Moon has moved ahead of the Sun. Rule PA-01 notes that the ayanamsa cancels out of that difference. So the tithi is the same in both zodiacs.

The panchang yoga is different. It adds the Sun's and Moon's positions, so the ayanamsa does not cancel out. Rule PA-02 uses sidereal positions for it. A tropical sum would name a different yoga.

Get John's chart from the API

Send the birth details to POST /v1/planets. Here is the request for John Doe, born Aug 15, 1990, at 10:30 AM in New York:

{
  "year": 1990,
  "month": 8,
  "day": 15,
  "hour": 10,
  "minute": 30,
  "latitude": 40.7128,
  "longitude": -74.006,
  "timezone": "America/New_York"
}

And here is part of the answer, with the Sun and the meta block:

{
  "positions": [
    {
      "name": "Sun",
      "longitude": 118.77534,
      "sign": "Cancer",
      "sign_number": 4,
      "degree_in_sign": 28.77534,
      "house": 11,
      "nakshatra": "Ashlesha",
      "pada": 4
    }
  ],
  "meta": {
    "ayanamsa": "lahiri",
    "ayanamsa_value": 23.726073
  }
}

Add 118.77534 and 23.726073 and you get 142.501413. That is 22.50° into Leo, John's Western Sun. To use a different ayanamsa, send ayanamsa as lahiri, kp or raman. The conventions page lists the API's defaults for the zodiac, houses and time zones.

For every field in the answer, with its type, see the API reference.

The hard part of going Vedic is not the one-line zodiac shift. It is the new shape of the data: whole sign houses, a Moon that leads, nakshatras, timelines and charts without degrees. Plan your data model for those first.