POST/api/nakshatra_dasha/1 credit

Nakshatra dashas

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.

https://yogataraapi.prahlad.app/api/nakshatra_dasha/

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
dasha_direction	string	required	`forwardbackward` Exact lower-case. Engine default 'forward'.
dasha_period	string	required	`mahadashaantardashapratyantardashasookshmashapranadashadehdashaall` Exact 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	`currentnextprevious` Exact lower-case. Chooses where the sub-period sequence starts relative to the parent lord. Engine default 'current'.
dasha_type	string	required	`VimshottariDashaAshtottariDashaChaturaseetiSamaDashaDwadashottariDashaDwisaptatiDashaPanchottariDashaSataabdikaDashaShodashottariDashaYoginiDashaShattrimsaSamaDashaBudhiGatiDasha` The 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	`gzipbzip2lzmanone` Default '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

Example request

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}'

Response

{
  "mahadasha": [
    {
      "mahadasha_lord": "saturn",
      "start_date": "2006-06-11 07:29:39.202770+00:00",
      "end_date": "2025-06-11 04:23:46.345170+00:00"
    },
    {
      "mahadasha_lord": "mercury",
      "start_date": "2025-06-11 04:23:46.345170+00:00",
      "end_date": "2042-06-11 12:59:33.788370+00:00"
    },
    {
      "mahadasha_lord": "ketu",
      "start_date": "2042-06-11 12:59:33.788370+00:00",
      "end_date": "2049-06-11 08:03:42.735570+00:00"
    },
    {
      "mahadasha_lord": "venus",
      "start_date": "2049-06-11 08:03:42.735570+00:00",
      "end_date": "2069-06-11 11:06:59.727570+00:00"
    },
    {
      "mahadasha_lord": "sun",
      "start_date": "2069-06-11 11:06:59.727570+00:00",
      "end_date": "2075-06-12 00:01:58.825170+00:00"
    },
    {
      "mahadasha_lord": "moon",
      "start_date": "2075-06-12 00:01:58.825170+00:00",
      "end_date": "2085-06-11 13:33:37.321170+00:00"
    },
    {
      "mahadasha_lord": "mars",
      "start_date": "2085-06-11 13:33:37.321170+00:00",
      "end_date": "2092-06-11 08:37:46.268370+00:00"
    },
    {
      "mahadasha_lord": "rahu",
      "start_date": "2092-06-11 08:37:46.268370+00:00",
      "end_date": "2110-06-12 23:22:43.561170+00:00"
    },
    {
      "mahadasha_lord": "jupiter",
      "start_date": "2110-06-12 23:22:43.561170+00:00",
      "end_date": "2126-06-13 01:49:21.154770+00:00"
    }
  ],
  "antardasha": [],
  "pratyantardasha": [],
  "sookshmasha": [],
  "pranadasha": [],
  "dehdasha": [],
  "_metadata": {
    "calculation_time_ms": 1.01,
    "max_levels": 1,
    "compression_type": "gzip",
    "created_at": "2026-09-05T12:47:39.333691",
    "total_periods": 9,
    "mahadasha_count": 9,
    "antardasha_count": 0,
    "pratyantardasha_count": 0,
    "sookshmasha_count": 0,
    "pranadasha_count": 0,
    "dehdasha_count": 0
  }
}

Captured from a real call using the exact request above. Results sit under data.

Errors

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