POST/api/astro/tajaka_yoga/1 credit

Tajika yogas

The Tajika yogas are the named planetary relationships used to judge whether a matter will actually come off, and they are the working tools of the annual solar-return chart (Varshaphala) and of horary work. The central pair is ithasala, where two planets are inside each other's orb and the faster one is still applying to the slower, taken as a promise that will be kept, and eesarpha, where the same two are separating, taken as an opportunity already gone. The rest qualify those: nakta and yamaya describe a third planet carrying the connection between two that do not aspect each other, kamboola brings the Moon into an ithasala, manahoo has Mars or Saturn spoiling one, and ishkavala and induvara are whole-chart patterns based on where the planets fall relative to the angles. The chart is built from `date_time`, `latitude`, `longitude` and `node`. Keys whose names begin `get_` take no further fields and scan the chart themselves, over the seven classical planets only, so Rahu and Ketu never appear in their output. `ithasala_yoga` and `eesarpha_yoga` take `planet1` and `planet2`; `check_yamaya_yoga` takes `planet` as well. Two keys are placeholders in the current build and return null rather than a result: `get_gairi_kamboola_yoga_planet_pairs` and `get_khallasara_yoga_planet_pairs`. Begin with `get_ithasala_yoga_planet_pairs`, which gives you every applying pair in the chart in one call, and use the single-pair keys only when you already know which two planets you care about.

https://yogataraapi.prahlad.app/api/astro/tajaka_yoga/

Test Request

Authentication

Send your key in the X-API-Key header. Keys are server-side credentials — never put one in browser JavaScript or a mobile app.

X-API-Key: yt_live_a1b2c3d4_…
Content-Type: application/json

Request fields

Field	Type	Required	Notes
date_time	string (date-time)	required	The moment to calculate for, ISO 8601. ALWAYS include an offset or a trailing Z - a value with no zone is read as Asia/Kolkata (UTC+05:30), not UTC, and can return the previous day's result with a 200. '2026-09-01T06:00:00Z' and '2026-09-01 06:00:00' are different instants and give different answers.
keys	array	required	Which calculations to return, as a list of names. See the key table for this endpoint; an unrecognised name rejects the whole request. One call costs one credit however many keys you ask for, so request everything you need at once rather than making several calls.
latitude	number (double)	required	Latitude of the place, in decimal degrees. Positive is north, negative is south. Example: 26.9124 for Jaipur, 40.7128 for New York. Minutes and seconds are not accepted - convert first. min -90 · max 90
longitude	number (double)	required	Longitude of the place, in decimal degrees. Positive is east, negative is west. Example: 75.7873 for Jaipur, -74.0060 for New York. Note the sign: a missing minus puts New York in China. min -180 · max 180
node	string	required	`truemean` Exact lower-case; interpolated into the chart celestial key name.
planet	string	required	`SunMoonMarsMercuryJupiterVenusSaturnRahuKetu` CASE-SENSITIVE, capitalised first letter only ('Mars', not 'mars' or 'MARS'. Confirmed empirically by the shipped catalogue verification results: planet='moon' returns 500 "'moon' is not in list" while planet1='Mars' succeeds.
planet1	string	required	`SunMoonMarsMercuryJupiterVenusSaturnRahuKetu` Capitalised, e.g. 'Mars' not 'mars'. A lowercase name returns 500.
planet2	string	required	`SunMoonMarsMercuryJupiterVenusSaturnRahuKetu` Capitalised, e.g. 'Mars' not 'mars'. A lowercase name returns 500.
timezone_as_float	number (double)	required	UTC offset of the place, in hours, as a decimal. Example: 5.5 for India (UTC+05:30), -5 for New York in winter, 5.75 for Nepal. This is NOT validated against date_time - if the two disagree you get a successful response for the wrong moment, so derive both from the same source. Use the offset in force on that date, not today's: a summer birth in a country with daylight saving needs the summer offset. min -12 · max 14

Available keys (13)

Ask for exactly the calculations you want by listing them in keys. An unknown key rejects the whole request, and you are charged 1 credit however many you ask for — so batch them.

Key	Extra fields needed	Description
check_yamaya_yoga	planet, planet1, planet2	Yamaya is the transfer of light through a slower planet: `planet1` and `planet2` have no aspect between them, but `planet` is in ithasala with both and stands at a higher longitude than either. Returns a single boolean for the specific triple you name.
eesarpha_yoga	planet1, planet2	The opposite of ithasala for the two planets you name: in aspect and inside each other's orb, but separating rather than approaching. Returns a single boolean. Read as a matter that was possible but has already slipped away.
get_eesarpha_yoga_planet_pairs	—	The separating-aspect equivalent of `get_ithasala_yoga_planet_pairs`: a list of two-element [planet1 name, planet2 name] entries for every pair in orb and in aspect but moving apart. Seven classical planets only, no extra request fields.
get_gairi_kamboola_yoga_planet_pairs	—	A placeholder in the current build: the method is unimplemented and returns null regardless of the chart. Takes no extra fields.
get_ithasala_yoga_planet_pairs	—	Scans the chart for every applying pair without you naming any planets. Returns a list of three-element entries, [planet1 name, planet2 name, ithasala type], where the type is 1 varthamaana, 2 poorna or 3 bhavishya. Only the seven classical planets are tested, so Rahu and Ketu never appear. The usual first call on this endpoint.
get_kamboola_yoga_planet_pairs	—	Kamboola is an ithasala that the Moon takes part in, read as a third party bringing the matter off. Returns a three-element array: a boolean, the list of Moon-involved pairs, and the list of ithasala pairs those planets also belong to. In the current build the Moon test compares a planet name against a numeric index, so it returns false with two empty lists whatever the chart.
get_khallasara_yoga_planet_pairs	—	A placeholder in the current build: the method is unimplemented and returns null regardless of the chart. Takes no extra fields.
get_manahoo_yoga_planet_pairs	—	Manahoo is an ithasala spoilt by a malefic. This walks the ithasala pairs and keeps those whose faster planet has Mars or Saturn sitting inside its deeptamsa orb, returning a list of three-element entries: the two planets of the pair and the sign in which the interfering malefic was found. Traditionally read as failure or trouble from enemies. Takes no extra fields.
get_nakta_yoga_planet_triples	—	Nakta is the case where two planets that do not aspect each other are both in ithasala with a third, faster planet less advanced than either, so the result arrives through an intermediary. Scans the chart for such triples and returns them as a flattened list of a carrier planet with the pair it links. Takes no extra fields.
get_yamaya_yoga_planet_triples	—	The chart-wide scan for the yamaya pattern that `check_yamaya_yoga` tests one triple of: pairs with no mutual aspect that are both linked to a third, more advanced planet. Returns a flattened list of the carrier planet with the pair it links. Takes no extra fields.
induvara_yoga	—	A single boolean for the whole chart, the mirror of ishkavala: true when every planet falls in an apoklima (3rd, 6th, 9th, 12th from the ascendant), leaving the kendras and panapharas empty — read as worry, illness and disappointment. Takes no extra fields.
ishkavala_yoga	—	A single boolean for the whole chart. True when every planet falls in a kendra (1st, 4th, 7th, 10th from the ascendant) or a panaphara (2nd, 5th, 8th, 11th), leaving the apoklimas empty — a configuration read as wealth and good fortune for the year. Takes no extra fields.
ithasala_yoga	planet1, planet2	The central Tajika yoga, an applying aspect between the two planets you name: they must be in aspect, inside each other's deeptamsa orb, and approaching rather than separating. Returns a two-element array of a boolean and the ithasala type — 1 varthamaana, 2 poorna, 3 bhavishya, null when absent. Traditionally read as a promise that the matter will come off.

Example request

curl -X POST https://yogataraapi.prahlad.app/api/astro/tajaka_yoga/ \
  -H "X-API-Key: $OCCULT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keys":["check_yamaya_yoga"],"planet":"Pluto","planet1":"Mars","planet2":"Saturn","node":"mean","date_time":"2025-02-12T09:13:52.017Z","latitude":26.9124,"longitude":75.7873,"timezone_as_float":5.5}'

Response

{
  "data": {
    "check_yamaya_yoga": false
  },
  "status": 200,
  "is_error": false,
  "message": "successful"
}

Captured from a real call using the exact request above. Results sit under data, keyed by what you requested.

Errors

Metering errors return { "error": "…", "message": "<code>", "is_error": true }. Show error to people and branch on message. See the error reference.