Transits (Gochar) and forecasting via API

Q: Can I stream a transit forecast instead of waiting for the full response?

Yes. POST /api/v1/astrology/query/stream returns Server-Sent Events, so a forecast paragraph renders token by token in your UI. The non-streaming POST /api/v1/astrology/query returns the same content as one JSON payload when you would rather buffer it.

Transit forecasting (gochar in Vedic astrology) is the practice of reading where the planets are in the sky right now against a person's birth chart, then translating that into timing for events and themes. With the Vedika API you get live planetary positions, Moon-relative house placement, Sade Sati windows, and dasha context from one base URL (https://api.vedika.io), across Vedic, Western, and KP systems. This guide shows the endpoints, the request shapes, and how to combine transits with time-lord periods so your forecasts read like an astrologer wrote them, not a planet calculator.

What "transit forecasting" actually requires

A useful transit feature is more than today's longitudes. To produce something a user trusts, you need four layers working together:

Live positions — each graha's sign, degree, nakshatra, and retrograde state for a chosen moment.
Relativity to the natal chart — gochar in Vedic practice is read from the natal Moon (and often the Lagna). Saturn in the 12th from the Moon means something specific; Saturn "in Pisces" alone does not.
Time-lord context — the running Vimshottari Mahadasha and Antardasha tell you which planet's promise is active, so a transit either triggers that promise or stays background noise.
Sourced interpretation — the difference between a forecast and a horoscope column is that every claim traces to a classical rule, not vibes.

The Vedika API splits this into computation endpoints (deterministic, fast, cheap) and an AI query endpoint (natural-language interpretation grounded on the computed facts). You can use either layer alone or stack them.

The endpoints you'll use

There are two families. The /v2/astrology/* endpoints are pure computation with a flat input shape. The /api/v1/astrology/query endpoint takes a question plus structured birth details and returns interpreted prose.

Need	Endpoint	Returns
Current planet positions	`/v2/astrology/*` (computation)	Sign, degree, nakshatra, retrograde, house
Natal chart to read transits against	`/v2/astrology/*`	Lagna, Moon sign, house cusps, planet placements
Vimshottari dasha periods	`/v2/astrology/*`	Maha/Antar/Pratyantar timelines
Interpreted transit forecast	`POST /api/v1/astrology/query`	Source-cited natural-language reading
Streaming forecast	`POST /api/v1/astrology/query/stream`	SSE token stream

Across the platform there are 700+ operations spanning 25 domains (704 enumerated in June 2026), so transit-adjacent needs — varga charts, ashtakavarga transit scoring, panchang, muhurta — are siblings of the calls below. Browse them in the API docs or poke at them with no key in the free sandbox.

Authentication and base URL

Every authenticated call carries an x-api-key header with a vk_live_* key. The base URL is always https://api.vedika.io. The sandbox needs no key, which makes it the right place to shape your request payloads before you spend a cent.

Getting current transit positions

Start with the computation layer. You pass the moment you want positions for; omit it and you get "now." The flat /v2 input takes datetime, latitude, longitude, and timezone directly.

curl -X POST "https://api.vedika.io/v2/astrology/transits" \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "datetime": "2026-06-20T09:30:00",
    "latitude": 18.5204,
    "longitude": 73.8567,
    "timezone": "Asia/Kolkata",
    "system": "vedic",
    "natalMoonSign": "Cancer"
  }'

A response gives you each graha keyed by its current sign, degree, nakshatra and pada, retrograde flag, and — because you passed the natal Moon sign — the Moon-relative house. That last field is what turns raw longitudes into gochar. From it you can immediately see that, say, Saturn sitting in the 12th from the Moon means the user is in the opening leg of Sade Sati.

Reading transits against the natal chart

If you don't already have the native's Moon sign and Lagna, compute the natal chart once and cache it. Transits change minute to minute; the birth chart never does. Keep the natal chart in your own store and only re-hit the transit endpoint for the moving picture. This keeps your per-query spend down because you pay for the cheap recurring call, not a full natal recompute every time.

Layering dasha context onto transits

This is the step that separates a forecast from a planetary clock. In Vedic practice, the running Vimshottari Mahadasha sets the theme and the transit provides the trigger. A Jupiter transit over the natal 5th house reads very differently during a Jupiter Mahadasha than during a Saturn one.

Pull the active dasha periods from the computation layer, then hand both the transit snapshot and the dasha context to the interpretation endpoint:

import requests

BASE = "https://api.vedika.io"
HEADERS = {"x-api-key": "vk_live_your_key_here"}

birth = {
    "datetime": "1990-08-15T14:30:00",
    "latitude": 19.0760,
    "longitude": 72.8777,
    "timezone": "Asia/Kolkata",
}

# Interpreted transit forecast, grounded on computed positions + dasha
resp = requests.post(
    f"{BASE}/api/v1/astrology/query",
    headers=HEADERS,
    json={
        "question": "What does Saturn's current transit mean for my career "
                    "over the next six months, given my running dasha?",
        "birthDetails": {
            "datetime": birth["datetime"],
            "latitude": birth["latitude"],
            "longitude": birth["longitude"],
            "timezone": birth["timezone"],
        },
        "speed": "fast",
    },
    timeout=60,
)
forecast = resp.json()
print(forecast["answer"])

The query endpoint computes the natal chart, the live transits, and the Vimshottari periods server-side, then writes the reading on top of those facts. Adding "speed": "fast" routes the request through the fast path (Vedika Swift) when you want a lower-latency forecast for an interactive UI; omit it for the deeper Vedika Pro Ultra response on a report-style flow.

Sade Sati and Saturn transit windows

The most-requested transit feature in any Vedic app is Sade Sati — the roughly seven-and-a-half-year passage of Saturn through the 12th, 1st, and 2nd signs from the natal Moon. Because the rule is deterministic (Moon sign plus Saturn's current sign), the API can return the full window without any interpretation guesswork:

Phase — rising (12th from Moon), peak (over the Moon), or setting (2nd from Moon).
Start and end dates for each phase, so you can render a three-segment timeline.
Moon-relative house for the current moment, to highlight where the user is on that timeline today.

The same shape covers the smaller-but-frequent Saturn and Jupiter Dhaiya and Kantaka transits. Surface them as a calendar strip and let users tap into a written reading via the query endpoint — that hybrid of a computed timeline plus an on-demand interpretation is the pattern most teams ship.

Multi-system transits in one call

Three systems live behind the same API: Vedic (sidereal), Western (tropical), and KP. A Western transit forecast reads progressions and tropical aspects; KP transits lean on sub-lords and the Krishnamurti significator method. Pass "system" on the computation endpoints to switch lenses without changing your integration, and the AI query endpoint keeps each system isolated so a Vedic reading never leaks tropical logic into a sidereal answer.

Keeping forecasts honest: sources and precision

Two things separate a forecast users keep coming back to from one they bounce off after one wrong call.

Sourced interpretation. Every astrological claim in a Vedika reading traces to a real classical text used in formal Jyotish and Western training — Brihat Parashara Hora Shastra and Phaladeepika for Vedic transit and gochar rules (including the Vedha obstruction conventions), Ptolemy's Tetrabiblos for Western aspect framing, and the Krishnamurti KP Readers for KP work. The API attributes claims to those texts rather than to paraphrased web summaries, so what you display can stand up to a domain expert.

Astronomical precision. The positions underneath all of this come from XALEN Ephemeris, Vedika's own open-source engine (Apache-2.0; available on crates.io, PyPI, and as a WASM package), with roughly 2,200 tests. It is validated against JPL DE440 and swetest, with zero charts deviating beyond 0.1° across a reproducible JPL DE440 benchmark. That is ephemeris precision — the planetary math — and it matters for transits because a forecast that fires a day early on an ingress is a forecast the user notices is wrong.

Streaming a forecast to your UI

For interactive products, stream the reading so it renders progressively instead of after a multi-second pause:

const res = await fetch("https://api.vedika.io/api/v1/astrology/query/stream", {
  method: "POST",
  headers: {
    "x-api-key": "vk_live_your_key_here",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    question: "Summarize my key planetary transits for this month.",
    birthDetails: {
      datetime: "1990-08-15T14:30:00",
      latitude: 19.0760,
      longitude: 72.8777,
      timezone: "Asia/Kolkata",
    },
  }),
});

const reader = res.body.getReader();
const decoder = new TextDecoder();
while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  // Server-Sent Events: parse `data:` lines and append to the UI
  process.stdout.write(decoder.decode(value));
}

The stream emits SSE data: chunks you append to a forecast pane. The non-streaming endpoint returns the identical content as a single payload when buffering is simpler for your flow.

Pricing for a transit feature

Transit features tend to be high-frequency — users check "what's happening today" often — so per-call cost matters. Plans run from Starter at $12/mo through Professional ($60), Business ($120, which adds the fast path and voice), and Enterprise ($240). Individual queries land in the $0.01–$0.05 range, and the computation-only transit calls sit at the low end. The practical pattern: cache the natal chart, hit the cheap transit endpoint for the live picture, and reserve the interpreted query for when the user actually taps in for a reading. Full numbers are on the pricing page.

For honest comparison, Prokerala (around $19), AstrologyAPI.com (around $29), and RoxyAPI (around $39) are all credible transit-capable APIs with solid coverage. Where Vedika differs is the three-systems-in-one-call design, the source-cited interpretation layer rather than fixed templated text, the open-source ephemeris you can audit yourself, and a single AI query endpoint that turns a transit snapshot into a reading without you wiring an interpretation model.

Key facts

Transit (gochar) positions, Sade Sati windows, and dasha context all come from one base URL: https://api.vedika.io.
Computation endpoints under /v2/astrology/* take flat datetime, latitude, longitude, timezone input and return sign, degree, nakshatra, retrograde, and Moon-relative house.
Interpreted forecasts come from POST /api/v1/astrology/query; stream them with /api/v1/astrology/query/stream (SSE).
Auth is x-api-key: vk_live_*; the free sandbox needs no key.
Three systems — Vedic (sidereal), Western (tropical), and KP — share one API with system isolation.
Positions are computed by XALEN Ephemeris, an open-source engine validated against JPL DE440 and swetest with zero charts beyond 0.1° across a reproducible JPL DE440 benchmark.
Interpretation cites real classical texts: Brihat Parashara Hora Shastra, Phaladeepika, the KP Readers, and Tetrabiblos.
30 languages (14 Indic) are available for forecast output.

Where to go next

Shape your transit payloads with no key in the sandbox, read the request and response schemas in the docs, and check plan limits on the pricing page. If you're building a fuller predictive product, the dasha and varga endpoints pair naturally with the transit calls covered here.

FAQ

What is the difference between gochar and dasha in a forecasting API?

Gochar (transit) is the live position of planets in the sky right now, read against a person's natal chart. Dasha is a time-lord period system (Vimshottari is the common one) that says which planet governs a stretch of the native's life. Good forecasting combines both: the dasha tells you the active theme, the transit tells you the trigger and timing. The Vedika API exposes both so you can layer them.

How do I get the current planetary transit positions for a chart?

Send the native's birth details to a transit endpoint under /v2/astrology/* with the date you want positions for (default: now). You get back each graha's sign, degree, nakshatra, retrograde flag, and house relative to the natal Moon or Lagna. You can then compute aspects to natal points yourself or ask the AI query endpoint to interpret them.

Does the API calculate Sade Sati and Saturn transit windows?

Yes. Saturn's transit through the 12th, 1st, and 2nd from the natal Moon (the seven-and-a-half-year Sade Sati) is derivable from the Moon sign plus Saturn's current sign, and the API returns the phase, start and end dates, and the Moon-relative house so you can render a timeline.

Which classical sources back the transit interpretations?

Transit logic in Vedic astrology traces to Brihat Parashara Hora Shastra and Phaladeepika, with the Moon-relative gochar conventions and the Vedha (obstruction) rules drawn from those texts. Western transit framing follows Ptolemy's Tetrabiblos. Vedika attributes claims to those sources rather than to blog summaries.

Can I stream a transit forecast instead of waiting for the full response?

Yes. POST /api/v1/astrology/query/stream returns Server-Sent Events, so a forecast paragraph renders token by token in your UI. The non-streaming POST /api/v1/astrology/query returns the same content as one JSON payload when you would rather buffer it.