Building a Western natal chart with an API

To build a Western natal chart with an API, send a person's birth datetime, latitude, longitude, and timezone to the Vedika API and request the Western system. You get back tropical planet positions, the Ascendant and Midheaven, twelve house cusps (Placidus by default), and the aspect grid between planets. This guide walks through the request shape, the data you receive, and working code in cURL, JavaScript, and Python against https://api.vedika.io.

What a Western natal chart actually contains

A natal chart is a snapshot of the sky at the exact moment and place of birth. The Western tradition uses the tropical zodiac, where 0° Aries is anchored to the spring equinox rather than to the fixed stars. This is the first thing to get right in an integration: the same birth data produces different sign placements in tropical (Western) versus sidereal (Vedic) frames, because of precession. Vedika computes both from one request, so you do not need two providers or two coordinate conventions.

Every natal chart is built from four families of data:

• Planetary longitudes — the Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn, plus Uranus, Neptune, and Pluto, each as a zodiacal longitude (sign + degree) and a house placement.
• Angles — the Ascendant (rising sign) and Midheaven (MC), derived from the timezone-corrected time and the geographic coordinates.
• Houses — twelve cusps that divide the chart. The Western default is the Placidus system; whole-sign is also available.
• Aspects — the angular relationships between planets (conjunction, sextile, square, trine, opposition) and their orbs.

The interpretive backbone of Western natal reading traces to Ptolemy's Tetrabiblos for the logic of aspects and planetary nature, and to centuries of later practice for house meanings. Vedika keeps interpretive claims attributable to such sources rather than to ungrounded prose.

The request shape

There are two layers you will use. The V2 computation endpoints under /v2/astrology/* return structured numeric data and take flat fields. The natural-language endpoint POST /api/v1/astrology/query returns a written reading and nests birth data under birthDetails. Both authenticate with an x-api-key header using a vk_live_* key.

For the chart computation, the required inputs are:

The single most common integration bug is the timezone. The Ascendant moves about one degree every four minutes of clock time, so a wrong offset — or ignoring historical daylight-saving rules — shifts the rising sign and rotates every house. Always pass an IANA timezone name and let the engine resolve the correct historical offset rather than hardcoding -05:00.

Generating the chart: cURL

Start in the free sandbox to see the response shape with no key, then switch the base URL and add your key for live data. Here is a Western natal computation request:

curl -X POST https://api.vedika.io/v2/astrology/natal-chart \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "datetime": "1995-07-14T09:25:00",
    "latitude": 40.7128,
    "longitude": -74.0060,
    "timezone": "America/New_York",
    "system": "western",
    "houseSystem": "placidus"
  }'

The response gives you the Ascendant, Midheaven, the ten planets with sign, degree, and house, the twelve cusps, and an aspect list. From there you can render a wheel, drive a feature, or feed the chart into the query endpoint for a written reading.

Generating the chart: JavaScript and Python

Node.js (fetch)

const res = await fetch("https://api.vedika.io/v2/astrology/natal-chart", {
  method: "POST",
  headers: {
    "x-api-key": process.env.VEDIKA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    datetime: "1995-07-14T09:25:00",
    latitude: 40.7128,
    longitude: -74.006,
    timezone: "America/New_York",
    system: "western",
    houseSystem: "placidus",
  }),
});

const chart = await res.json();
console.log("Ascendant:", chart.ascendant);   // e.g. { sign: "Virgo", degree: 12.4 }
console.log("Sun:", chart.planets.sun);       // sign, degree, house
console.log("Aspects:", chart.aspects.length);

Python (requests)

import os, requests

payload = {
    "datetime": "1995-07-14T09:25:00",
    "latitude": 40.7128,
    "longitude": -74.0060,
    "timezone": "America/New_York",
    "system": "western",
    "houseSystem": "placidus",
}

resp = requests.post(
    "https://api.vedika.io/v2/astrology/natal-chart",
    json=payload,
    headers={"x-api-key": os.environ["VEDIKA_API_KEY"]},
    timeout=30,
)
chart = resp.json()

print("Ascendant:", chart["ascendant"])
for name, body in chart["planets"].items():
    print(name, body["sign"], round(body["degree"], 2), "house", body["house"])

From raw chart to a written reading

If you want narrative output rather than only numbers, post the same birth data to the query endpoint. It computes the chart internally and returns a reading grounded in the computed positions:

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": "Describe the rising sign and Sun placement in this Western natal chart.",
    "system": "western",
    "birthDetails": {
      "datetime": "1995-07-14T09:25:00",
      "latitude": 40.7128,
      "longitude": -74.0060,
      "timezone": "America/New_York"
    }
  }'

For interactive UIs, the streaming variant POST /api/v1/astrology/query/stream emits the reading as Server-Sent Events so you can render tokens as they arrive. Add "speed": "fast" to trade some depth for lower latency on the response path. The narrative is produced by Vedika Pro Ultra for the standard path and Vedika Swift for the fast path; both read from the same computed chart, so the numbers never disagree with the prose.

House systems and angles in practice

Western charts default to Placidus, the time-based system most desktop and web astrology tools use, because it matches what your users likely expect from other software. The trade-off is that Placidus cusps become unstable at high latitudes (above roughly 66°), where some houses can collapse. If you serve users near the poles, request whole-sign houses, which assign one full sign to each house starting from the Ascendant's sign and never degenerate.

Both house systems are derived from the same Ascendant and Midheaven, so switching is a parameter change, not a recomputation. The Midheaven anchors the 10th-house cusp in Placidus and is itself a useful angle for career and public-life questions in Western practice.

Three systems, one integration

The reason to compute a Western chart through Vedika rather than a single-tradition tool is breadth. The same birth details, with system set to vedic or kp, return a sidereal Vedic chart or a Krishnamurti Paddhati chart respectively — plus Jaimini, Tajaka, Lal Kitab, and numerology where relevant. That matters if your product serves a mixed audience or you want to show, for example, both a tropical Sun sign and a sidereal one side by side. Single-system providers such as Prokerala, AstrologyAPI.com, and RoxyAPI each cover their domain well; Vedika's differentiator is consolidating Western, Vedic, and KP under one auth, one request shape, and one ephemeris.

That ephemeris is the XALEN Ephemeris, Vedika's own open-source engine (Apache-2.0, available on crates.io, PyPI, and as a WASM package). It is validated against reference ephemerides with results staying within a tenth of a degree across a multi-million-chart test corpus. Positions are computed in-house, not proxied, which keeps latency predictable and the math auditable.

Key facts

• Western natal charts use the tropical zodiac; request system: "western".
• Required inputs: datetime, latitude, longitude, and an IANA timezone.
• Default house system is Placidus; whole-sign is available and safe at high latitudes.
• Computation lives at /v2/astrology/*; written readings at POST /api/v1/astrology/query (SSE streaming variant available).
• Authentication uses an x-api-key: vk_live_* header against https://api.vedika.io.
• One API spans 700+ operations across 25 domains and three systems — Vedic, Western, and KP.
• Positions come from the open-source XALEN Ephemeris, validated to within a tenth of a degree across millions of test charts.

Where to go next

Try a Western natal request in the free sandbox with no key to confirm the response shape, then read the field-by-field reference in the API docs. When you are ready to compare plans and per-query costs, see pricing. If you also need sidereal output, the companion walkthrough on building a Vedic birth chart covers the same birth data in the Vedic frame.

FAQ

Does the Western natal chart API use tropical or sidereal zodiac?

The Western system uses the tropical zodiac, with 0° Aries fixed to the spring equinox. Set system: "western" and longitudes return tropical. The same birth data also yields Vedic (sidereal) and KP charts from one integration.

What birth details do I need to compute a natal chart?

A full birth datetime, latitude, longitude, and an IANA timezone such as America/New_York. The timezone is load-bearing: the Ascendant rotates about a degree every four minutes, so a wrong offset shifts the rising sign and every house.

Which house system does the Western natal chart use?

Placidus by default, matching common Western software. Whole-sign is also available and is the safer choice above roughly 66° latitude where Placidus cusps can degenerate.

Can I get a written interpretation as well as the raw data?

Yes. /v2/astrology/* returns structured numbers; POST /api/v1/astrology/query returns a reading grounded in the same computed chart, with claims traceable to classical sources.