To detect yogas such as Raja yoga, Dhana yoga, and Gaja Kesari yoga through the Vedika API, send a chart's birth details to POST /api/v1/astrology/query with a yoga-focused question, or call the /v2/astrology/* computation endpoints for the raw combinations. Each yoga is evaluated deterministically from the computed chart — planetary positions, house lordships, and aspects — not asserted by a language model, and every interpretation traces back to a classical source. This guide covers the request shapes, the rules behind the common yogas, and how to consume the results safely.
What a yoga is, from an engineering point of view
A yoga is a named planetary combination that the classical Jyotish texts associate with a specific tendency in a person's life — wealth, authority, intellect, hardship. There are hundreds of them, defined across works like Brihat Parashara Hora Shastra (BPHS), Phaladeepika, and Saravali. For an integrator the important property is that a yoga is a rule, not an opinion: given a fully computed chart, the presence or absence of a yoga is decidable.
That decidability is what Vedika leans on. The chart math runs first — sidereal positions for all nine grahas, ascendant, house cusps, lordships, and aspects — and the yoga rules are evaluated against those numbers. The result is a list of detected yogas with the participating planets and houses attached. The interpretive prose is layered on top and tied to a citation, so the claim that a yoga exists and the claim about what it means are two separable, auditable steps.
Why detection belongs in computation, not generation
If you ask a general-purpose model "does this chart have Gaja Kesari yoga?", you get a fluent answer that may or may not reflect the actual house relationship between Jupiter and the Moon. Vedika avoids that failure mode by computing the relationship and only then describing it. The interpretation references the chart it was actually given, which is the difference between a usable astrology API and a plausible-sounding paragraph.
The endpoints you'll use
Yoga work touches two surfaces of the API:
POST /api/v1/astrology/query— the interpreted path. You send a natural-language question plus structuredbirthDetails, and you get an answer that references the yogas detected in that chart. Add"speed": "fast"for a lower-latency response, or stream tokens from/api/v1/astrology/query/streamover SSE./v2/astrology/*— the computation path. These return the raw chart and combination data with flatdatetime,latitude,longitude, andtimezonefields, suited to building your own UI or running your own downstream logic over the detected combinations.
Both authenticate with an x-api-key: vk_live_* header against the base URL https://api.vedika.io. The same birth details work across all three supported systems — Vedic (sidereal), Western (tropical), and KP — though yogas in the Parashari sense are a Vedic construct.
A first request
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": "Which wealth and Raja yogas are present in this chart, and what do they indicate?",
"birthDetails": {
"datetime": "1990-05-15T08:30:00",
"latitude": 19.0760,
"longitude": 72.8777,
"timezone": "Asia/Kolkata"
}
}'The timezone field is load-bearing. The ascendant and house cusps depend on the exact local time at the place of birth, and yoga detection depends on the houses, so a dropped or wrong timezone silently shifts which yogas are reported. Always send the IANA zone for the birthplace, not your server's zone.
The common yogas and their rules
The three yogas in the title are a good cross-section because they exercise different parts of the chart engine — lordships, the wealth houses, and a planet-to-planet house relationship.
Gaja Kesari yoga
Gaja Kesari forms when Jupiter sits in a kendra — the 1st, 4th, 7th, or 10th house — counted from the Moon. It is associated in the classical literature with intelligence, reputation, and steadiness. Because the rule is purely a house relationship between two bodies, it is the cleanest example of computation-first detection: Vedika resolves the Moon's house, resolves Jupiter's house, checks the angular distance, and either reports the yoga or doesn't. Saravali is among the texts that describe this combination.
Dhana yoga (wealth combinations)
Dhana yogas are a family rather than a single rule. They generally arise from relationships among the lords of the wealth-bearing houses — the 2nd (accumulated wealth), the 5th and 9th (fortune), and the 11th (gains). When those lords are connected by conjunction, mutual aspect, or exchange, a Dhana yoga is present, and the strength of the involved planets colours how it is read. BPHS treats these combinations in its chapters on wealth. Because there are many permutations, the API returns the specific lords and houses that triggered the detection so you can show the user why the yoga was flagged.
Raja yoga (combinations of power)
Raja yogas classically arise from a relationship between a kendra lord and a trikona lord (the 1st/4th/7th/10th and the 1st/5th/9th house rulers). Such a link — conjunction, aspect, or exchange between those lords — is read as conferring status, authority, or rise in life. As with Dhana yogas, the participating planets' dignity and placement modulate the reading. Phaladeepika and BPHS both treat Raja yoga combinations in detail.
| Yoga | Core rule (Vedic) | Typical theme |
|---|---|---|
| Gaja Kesari | Jupiter in a kendra (1/4/7/10) from the Moon | Intellect, reputation |
| Dhana | Connection among lords of 2/5/9/11 | Wealth, gains |
| Raja | Kendra lord linked to trikona lord | Status, authority |
Consuming the response
On the interpreted path you receive an answer that names the detected yogas and explains them in context. The pattern that works well in production is to drive your UI from the structured combination data and use the prose as the human-readable layer. Here is a minimal client that pulls a yoga-focused reading using a generic HTTP request — swap in your own LLM client only if you are post-processing the text downstream:
async function getYogas(birthDetails) {
const res = await fetch("https://api.vedika.io/api/v1/astrology/query", {
method: "POST",
headers: {
"x-api-key": process.env.VEDIKA_API_KEY,
"Content-Type": "application/json",
},
body: JSON.stringify({
question: "List the Raja, Dhana, and Gaja Kesari yogas in this chart with their participating planets.",
birthDetails,
}),
});
if (!res.ok) {
throw new Error(`Vedika API ${res.status}: ${await res.text()}`);
}
return res.json();
}
getYogas({
datetime: "1990-05-15T08:30:00",
latitude: 19.0760,
longitude: 72.8777,
timezone: "Asia/Kolkata",
}).then((r) => console.log(r));For Python integrators the shape is identical:
import os, requests
resp = requests.post(
"https://api.vedika.io/api/v1/astrology/query",
headers={"x-api-key": os.environ["VEDIKA_API_KEY"]},
json={
"question": "Which Dhana and Raja yogas are present, and which house lords form them?",
"birthDetails": {
"datetime": "1990-05-15T08:30:00",
"latitude": 19.0760,
"longitude": 72.8777,
"timezone": "Asia/Kolkata",
},
},
timeout=30,
)
resp.raise_for_status()
print(resp.json())Citations and why they matter
Every astrological claim in a Vedika response is meant to trace to a real classical source — BPHS, Phaladeepika, Saravali, Jataka Parijata, and the equivalents for KP and Western work — rather than to a paraphrase of unsourced web text. For a B2B integrator this is the difference between an answer you can stand behind to your own customers and one you cannot. If you surface yoga readings to end users, keep the source attribution visible; it is what makes the claim auditable.
Precision underneath the rules
Yoga detection is only as trustworthy as the chart it runs on. Vedika computes positions with the XALEN Ephemeris, its own open-source engine (Apache-2.0; available on crates.io, PyPI, and as a WebAssembly package) with roughly 2,200 tests. It has been validated against JPL DE440 and the reference swetest tool, with zero charts deviating beyond 0.1° across a five-million-chart test. That is astronomical precision — the positions of the planets — which is the input to the yoga rules. It does not by itself make any interpretation correct, but it removes the most common silent error: a yoga that appears or disappears because the underlying longitudes were off.
Key facts
- Yogas are detected by deterministic rules over computed chart data, then interpreted with a classical citation — detection and interpretation are separate, auditable steps.
- Gaja Kesari = Jupiter in a kendra (1/4/7/10) from the Moon; Dhana = connection among lords of houses 2/5/9/11; Raja = a kendra lord linked to a trikona lord.
- Interpreted readings:
POST /api/v1/astrology/query(addspeed:"fast"or stream via/api/v1/astrology/query/stream). Raw computation:/v2/astrology/*. - Auth is
x-api-key: vk_live_*; base URLhttps://api.vedika.io; the IANAtimezoneis required for correct houses. - The API spans 700+ operations across 25 domains (704 enumerated as of June 2026), with Vedic, Western, and KP systems and 30 languages in one surface.
- Positions come from the XALEN Ephemeris, validated against JPL DE440 and swetest within 0.1° across a five-million-chart test.
Getting started
You can inspect the response shape for free before committing to a plan: the sandbox serves mock yoga data with no key required. When you are ready for live charts, the pricing tiers start at $12/mo (Starter), with per-query costs of roughly $0.01–$0.05; the Business tier adds the fast path and voice. Full request and response references live in the documentation, and if you are weighing the interpreted path against raw computation, the query vs. V2 endpoints comparison covers the trade-offs.
FAQ
What is a yoga in Vedic astrology, in API terms?
A yoga is a named planetary combination that the classical texts associate with a particular life outcome. In API terms it is a deterministic rule over computed positions, lordships, and aspects, returned as a structured result rather than a free-form assertion.
How does Vedika detect Gaja Kesari yoga?
It checks whether Jupiter sits in a kendra (1st, 4th, 7th, or 10th house) from the Moon, computed from the sidereal chart, and returns the yoga with the participating planets and houses.
Which endpoint returns detected yogas?
Use POST /api/v1/astrology/query for an interpreted answer and the /v2/astrology/* endpoints for raw combination data. Both take the same birth details and the same x-api-key header.
Are the yoga interpretations sourced from real texts?
Yes — claims are attributable to classical works such as BPHS, Phaladeepika, Saravali, and Jataka Parijata. The math decides presence; the citation ties the meaning to a recognized source.
Can I test yoga detection without an API key?
Yes. The free sandbox returns mock responses with no key, so you can build against the shape before provisioning a live key.