curl -X POST https://yogataraapi.prahlad.app/api/nakshatra_dasha/ \
-H "X-API-Key: $OCCULT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"dasha_type":"VimshottariDasha","dasha_period":"all","datetime":"2024-11-21T09:21:43.577Z","latitude":26.1046,"longitude":74.319,"timezone_as_float":5.5,"days_in_year":365.256364,"dasha_start":"current","dasha_direction":"forward","compressed_output":true,"max_levels":1,"use_cache":true,"use_nested":true,"save_to_file":true,"compression_type":"gzip","output_dir":"dasha_output","ultra_fast":true}'A dasha is a timeline that divides a life into periods, each ruled by a planet. The nakshatra dashas start from the lunar mansion the Moon occupied at birth: that fixes which planet's period was running at birth and how much of it remained, and the rest of the cycle follows in a fixed order. Vimshottari, the 120-year scheme, is the one in general use; the others suit charts where their own applicability conditions are met. `dasha_type` selects the scheme, and the schemes differ in total length and in which planets take part. VimshottariDasha runs 120 years over nine planets; AshtottariDasha 108 over eight (Ketu is omitted); ChaturaseetiSamaDasha 84, as seven equal twelve-year periods; DwadashottariDasha 112; DwisaptatiDasha 72, as eight equal nine-year periods; PanchottariDasha 105; SataabdikaDasha 100; ShodashottariDasha 116; ShattrimsaSamaDasha and YoginiDasha both 36 over eight periods of one to eight years, differing in how the first lord is chosen; and BudhiGatiDasha 120 over a ten-step sequence. Note that YoginiDasha reports its periods by ruling planet rather than by the eight yogini names. `dasha_period` chooses the depth: mahadasha, antardasha, pratyantardasha, sookshmasha, pranadasha, dehdasha, or 'all' for the nested structure. `dasha_start` ('current', 'next' or 'previous') and `dasha_direction` ('forward' or 'backward') position the sequence relative to the birth moment, and `days_in_year` sets the year length used to convert periods into dates — pass 365.256364 for the sidereal year or 360 for the traditional savana reckoning, which shifts every date. `max_levels` caps the nesting depth and is the main lever on response size, since a full six-level Vimshottari expansion runs to hundreds of thousands of rows. The response is `{data: {<dasha_type>: …}}`. Each period is `{mahadasha_lord, start_date, end_date}` at the top level, with the sub-period lords added at deeper levels, plus a `_metadata` block giving the calculation time and a count per level. Setting `save_to_file` true changes the response entirely: the body becomes a compressed file download in the format named by `compression_type` rather than JSON.
| Field | Type | Required | Notes |
|---|---|---|---|
| dasha_direction | string | required | forwardbackwardExact lower-case. Engine default 'forward'. |
| dasha_period | string | required | mahadashaantardashapratyantardashasookshmashapranadashadehdashaallExact lower-case. 'all' returns the full nested tree; any other listed value extracts just that level from the computed tree and returns [] if that level is absent. Note the spellings 'sookshmasha' (not sookshmadasha) and 'dehdasha' (not dehadasha). |
| dasha_start | string | required | currentnextpreviousExact lower-case. Chooses where the sub-period sequence starts relative to the parent lord. Engine default 'current'. |
| dasha_type | string | required | VimshottariDashaAshtottariDashaChaturaseetiSamaDashaDwadashottariDashaDwisaptatiDashaPanchottariDashaSataabdikaDashaShodashottariDashaYoginiDashaShattrimsaSamaDashaBudhiGatiDashaThe value is used verbatim as a CoreEngine registry key, so it must be the exact CamelCase class name. Note the registry key is spelled 'BudhiGatiDasha' even though the module is. |
| datetime | 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. Same meaning as date_time, which other endpoints call the same thing by a different name. |
| days_in_year | number (double) | required | min 360 · max 365.256364 |
| 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 |
| 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 |
| compressed_output | boolean | optional | |
| compression_type | string | optional | gzipbzip2lzmanoneDefault 'gzip'. Only has an effect when save_to_file=true, in which case the response body is the raw compressed file with Content-Type application/gzip | application/x-bzip2 | application/x-xz | application/json respectively. |
| max_levels | integer | optional | min 1 · max 6 |
| output_dir | string | optional | |
| save_to_file | boolean | optional | |
| use_cache | boolean | optional | |
| use_nested | boolean | optional |