The World's Most Comprehensive
Hindu Panchang API

Supports 1700–3100 date range. Automatically detects region (India/Nepal/Kashmir) from coordinates. Nepal gets +05:45 timezone. Includes engine version attribution on every response.

Returns Panchang for today (server time, IST). Accepts all optional params except date.

Returns Panchang for tomorrow. Useful for apps that show a next-day preview widget.

Returns every available section in one response: core panchang, timings, hora, choghadiya, astronomical, shastric conditions, event suitability, festivals, panchak, bhadra, disha shool, special yogas.

Returns Tithi number, name, paksha (Shukla/Krishna), nature (Nanda/Bhadra/Jaya/Rikta/Purna), start/end times.

Returns Nakshatra number, name, pada (quarter), deity, gana (Deva/Manushya/Rakshasa), nature, ruling planet, period times.

Every key /v1/panchang/full?include=day_classification can emit, once.

Domain facts (authoritative): key, kind, type, category, priority_tier, default_priority, nature. Presentation hints (guidance for the client's own design system): presentation.icon_key, theme_key, badge_key. Icon keys are hierarchical (festival.diwali falls back to festival). No colours and no asset URLs are published.

Cache it: the response carries catalog_version and an ETag; send If-None-Match to receive 304 Not Modified until the catalogue changes.

Lightweight Panchang for mobile apps. Returns only essential data: date, tithi, nakshatra, sunrise, sunset, paksha. Response size < 1KB. For full data use /v1/panchang.

Get Panchang for current moment with live running tithi/nakshatra info. Shows what's active RIGHT NOW.

Panchang for each date from start to end inclusive (end - start <= 30 days, i.e. at most 31 dates). Requires the Starter plan; single dates are available on Free from /v1/panchang. Location: location_id > lat/lon > region's canonical location > Ujjain (the historical default).

Get Panchang for yesterday.

Killer endpoint: Returns today's complete Panchang data in a single call. Includes: panchang, festivals, muhurat, rahukaal, moon phase — everything. Optimized for mobile apps and dashboard widgets.

Returns: 🌅 Sunrise/Sunset · 🌙 Moonrise/Moonset · 🔴 Rahu Kaal · ⚫ Yamagandam · 🟠 Gulika Kaal · ⭐ Brahma Muhurta · ✨ Abhijit Muhurat · 💫 Amrit Kaal · ❌ Durmuhurta (×2) · 🚫 Varjyam.

Get inauspicious timings (Rahu Kaal, Yamagandam, Gulika Kaal, Durmuhurta, Varjyam).

24 Hora periods from sunrise to next sunrise. Each ruled by a planet (Sun→Venus→Mercury→Moon→Saturn→Jupiter→Mars). Duration = (next_sunrise − today_sunrise) / 24. Nepal uses +05:45 correctly.

North/West Indian tradition. 8 day slots from sunrise→sunset and 8 night slots from sunset→sunrise. Each ~1.5 hours (dynamically computed), rated: Amrit ✅ · Shubh ✅ · Labh ✅ · Char ⚠️ · Rog ❌ · Kaal ❌ · Udveg ❌.

Inauspicious 1.5-hour window. Varies by weekday — computed from actual sunrise, not fixed times.

Another inauspicious daily period. Avoid new ventures during Yamagandam.

Third inauspicious daily window in the Vedic timekeeping system.

Abhijit Muhurat — near solar noon, ~48 minutes. Most universally auspicious window. Not applicable on Wednesdays by traditional rule.

Sun longitude/rashi, Moon longitude/rashi/nakshatra, sankranti day flag, amavasya/purnima flags, planetary positions.

Returns phase name (Waxing Crescent/Gibbous/Full/Waning etc.), illumination percentage, paksha (Shukla/Krishna), days to next full/new moon.

Lagna (ascendant) changes every ~2 hours. Returns current lagna rashi + udaya lagna (fixed at sunrise). For real-time widgets, refresh every 5 minutes.

Get sun position and timing data.

Returns complete daily spiritual intelligence in a single response: panchang (5 limbs + hindu calendar), festivals (stored + rule-derived), conditions (panchak, bhadra, ganda_mool), and astronomical.eclipse. Internally calls the same engine functions as the individual endpoints — no logic duplication, no extra HTTP overhead. Any sub-block that cannot be computed returns null instead of failing.

curl "https://api.tathaastuapi.com/v1/day-context?date=2026-04-11&lat=28.6139&lon=77.2090" \
  -H "X-API-Key: sk_live_xxxxxxxxxxxx"

{
  "date": "2026-04-11",
  "location": { "lat": 28.6139, "lon": 77.2090, "region": "NORTH_INDIA", "location_id": 2 },
  "panchang": { /* tithi, nakshatra, yoga, karana, hindu_calendar, ... */ },
  "festivals": [ /* stored + rule-derived festivals */ ],
  "conditions": {
    "panchak":    { "is_panchak": false, "type": null, /* ... */ },
    "bhadra":     { "is_bhadra": false, /* ... */ },
    "ganda_mool": { "is_ganda_mool": false, "nakshatra_num": 12, "nakshatra_name": "Uttara Phalguni", "gana": "Manushya" }
  },
  "astronomical": {
    "eclipse": null
  },
  "_note": "Panchak, Bhadra, and Ganda Mool are NOT festivals. They are shastric conditions surfaced separately from /v1/festivals."
}

Returns a personalised Isht Devta recommendation based on the caller's birth data, computed via the production Vedic astrology engine. Deterministic and explainable — no hardcoded charts.

Request body:

{
  "date_of_birth": "1992-07-18",
  "time_of_birth": "10:30",
  "location": { "lat": 28.6139, "lon": 77.2090 },
  "timezone": "Asia/Kolkata"
}

Response:

{
  "isht_devta": {
    "name": "Mahalakshmi",
    "basis": "lagna_lord=Venus; moon_sign_lord=Venus; nakshatra_lord=Sun; → dominant planet: Venus",
    "confidence": "medium"
  },
  "methodology": "lagna + moon + nakshatra convergence",
  "supporting_factors": {
    "nakshatra":       "Punarvasu",
    "nakshatra_deity": "Aditi",
    "rashi":           "Taurus",
    "lagna":           "Libra",
    "lagna_lord":      "Venus",
    "moon_sign_lord":  "Venus",
    "nakshatra_lord":  "Sun",
    "dominant_planet": "Venus"
  },
  "engine": {
    "name": "TathaAstu Vedic Astrology Engine",
    "ayanamsa": "Lahiri",
    "rule": "convergence(lagna_lord, moon_sign_lord, nakshatra_lord)"
  },
  "disclaimer": "Isht Devta is a personal devotional choice. This recommendation is a deterministic computation based on classical lordships and is intended as guidance, not prescription. Consult your family guru or priest for personal sadhana decisions."
}

curl -X POST https://api.tathaastuapi.com/v1/isht-devta \
  -H "X-API-Key: sk_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"date_of_birth":"1992-07-18","time_of_birth":"10:30","location":{"lat":28.6139,"lon":77.2090}}'

Bulk endpoint for calendar grids / monthly views / annual sync jobs.

Accepts a date range (up to 62 days per call) and returns an array of day_context payloads — avoids the 60 req/min rate limit when syncing full months or years.

Usage patterns:

• Mobile monthly calendar: 1 call per month × 7 regions = 7 calls/year
• Annual sync (single region): 12 calls (one per month)
• Annual sync (all regions): 84 calls (vs ~2,555 with daily endpoint)

Region parameter: If region=NORTH_INDIA is passed, canonical coords are auto-resolved. If region is omitted, lat + lon are required.

Location: each day is exactly /v1/day-context for the same inputs. With lat+lon (+tz) and no location_id/region, every day is computed for those coordinates and festivals equal /v1/festivals?lat&lon&tz. location_id used to default to 2 (Varanasi), so coordinate-only callers were answered for Varanasi; an explicit location_id or region still selects that stored location.

Response shape: ``json { "from": "2026-04-01", "to": "2026-04-30", "region": "NORTH_INDIA", "count": 30, "days": [ {"date": "2026-04-01", ...full day_context...}, ... ] } ``

Explainability endpoint — returns the exact astronomical rule that triggered a derived festival, with per-condition match details.

{
  "festival": "FESTIVAL_MAHA_SHIVARATRI",
  "date": "2026-02-16",
  "matched": true,
  "rule_code": "SHIVARATRI",
  "conditions": [
    { "field": "paksha", "expected": "KRISHNA", "actual": "KRISHNA", "matched": true },
    { "field": "tithi_num", "expected": 14, "actual": 14, "matched": true },
    { "field": "purnimanta_month", "expected": "Phalguna", "actual": "Phalguna", "matched": true }
  ],
  "human_readable": "This festival was derived because the conditions in rule 'SHIVARATRI' matched the Panchang facts for 2026-02-16."
}

Every festival that has content: its subject (slug), the piece types held (katha = the story, significance, vidhi = how it is observed) and their English titles. Draft content by TathaAstu; see notice.

One festival's content, e.g. rishi-panchami, karva-chauth, indira-ekadashi. Each piece has title, body_html (simple HTML: p, em, strong, ul/li), language actually served, and provenance: who wrote it, the scriptural or traditional source it adapts (source_reference, always source_reference_verified: false until reviewed), review_status and, for a translation, how it was made.

Alias for /v1/festivals?date=X

Auspicious muhurat window for a festival at a specific date and location.

TathaAstuAPI owns all festival / muhurat / regional computation; the consuming app renders recommended + explanation directly and implements NO religious or regional logic. The response contains everything needed to display the answer:

• festival (id, key, name, date)
• location (region, lat, lon, timezone_offset)
• recommended {start, end, label} (null when unsupported / not applicable)
• avoid [{start, end, reason, label}] (Bhadra Mukha, Rahu Kaal, ...)
• conditions {tithi, sunrise, sunset, rahu_kaal, bhadra?, moonrise?}
• explanation {rule, kala, reason, source}
• kala {code, label} (present when the rule defines one of the four kalas)
• timing {type, status, windows} — the explicit timing contract
• verification : "verified" | "computed" | "unsupported"
• source

timing.type is INSTANT | WINDOW | MULTI_WINDOW | NONE, and timing.status is supported | unsupported | not_applicable | error, so the caller never has to infer capability from the shape of recommended. timing.windows carries every window the rule produced; recommended remains the single window the engine selects. not_applicable means the authored rule selects the day and states no performance hour.

verification is honest: Tier-1 festivals are source-traced ("verified"), Tier-2 are computed from the authored kala ("computed"), and unsupported festivals return recommended: null rather than a fabricated time. Times are local ISO-8601 (the location's timezone, see location.timezone_offset).

What the muhurat engine can actually time, and under which contract.

Each entry carries the canonical key, its accepted slugs, the timing contract (timing_type, timing_status) and, where the rule defines one, the kala. This is the list the consuming app should build against instead of guessing slugs or inferring capability from a null recommended.

• timing_type : INSTANT | WINDOW | MULTI_WINDOW | NONE
• timing_status : supported | unsupported | not_applicable

not_applicable means the authored rule selects the observance day and states no performance window. That is a property of the source, not a gap in the engine, and the engine does not invent an hour to fill it.

Get all festivals in a date range using the rule engine.

Every day is evaluated exactly as /v1/festivals evaluates it, with the same region rule. A listed location without precomputed rows is computed from its coordinates; an unknown location_id is a 404; any other failure surfaces instead of silently dropping that day's festivals.

Search festivals by name or tag.

Get all festivals for a specific year.

The śrāddha kālas of one civil day at your coordinates: aparāhṇa (4th of 5 parts of daylight), Kutapa (8th of 15 day-muhūrtas), Gāndharva and Rauhiṇa (7th and 9th), and the kālas in which pārvaṇa is forbidden — prātaḥ, saṅgava and sāyāhna (Dharmasindhu ch. 26).

tithis_in_aparahna lists every tithi present in that day's aparāhṇa with the overlap in minutes, which is what an annual (pratyābdika) śrāddha is decided on. Two tithis appear when one ends inside the aparāhṇa.

The fifteen tithis of Mahālaya Pakṣa — amānta Bhādrapada Kṛṣṇa Pratipadā to Amāvāsyā — with the civil day each tithi's śrāddha falls on at your coordinates.

The day rule is the Dharmasindhu's: pārvaṇa śrāddha "has to be of Aparaahna Praapti" — the tithi must be present in the aparāhṇa, the fourth of five equal parts of daylight (ch. 26). Every rule in the response carries its verbatim quotation, chapter and URL under sources.

Where the text does not decide, neither does the API. When a tithi is present in the aparāhṇa on two days, or on neither, observance_date is null, decision_status is REQUIRES_SOURCE_CERTIFICATION, and both candidate days are returned with their overlap in minutes. The consulted text gives no pūrva/para ruling for pārvaṇa Mahālaya, and borrowing one would put authority on a rule the source did not state.

Also returned: Kutapa muhūrta per day, Śastrahata Caturdaśī, the Bharaṇī and Maghā-Trayodaśī occasions, the stated phala of each tithi, and the Kanyā-to-Vṛścika extension window. Avidhavā Navamī and Yati Dvādaśī are reported as convention, because the consulted translation does not state them.

Because sunrise and sunset set the aparāhṇa, the result depends on where you are.

Vrat and fasting observances for a date.

This used to read vrat_observance, joined to vrats and panchang_day_core. vrats holds 24 definitions; vrat_observance holds ZERO rows, in the active slot, the standby slot and the DB_NAME schema alike. It was never populated, so the join could not match and the endpoint returned {"vrats": [], "count": 0} for every date ever requested. July 2025 has two Ekadashis, two Pradosh, a Purnima, an Amavasya and a Sankashti; all thirty-one days came back empty, including 6 July, Devshayani Ekadashi, which /v1/festivals reported correctly as VRAT_EKADASHI on the same call.

It now resolves through canonical_festivals, like every other festival-producing endpoint. That was already the stated rule -- "one festival cannot come back on two different dates depending on which endpoint a client happened to call" -- and this endpoint was simply never brought across. Doing so also means it inherits the kala-aware rules, including the Caturthi-nirnaya fix, rather than a table nobody fills.

The {code, category, name} shape callers parsed is preserved; rule_code and confidence are added so a caller can see which rule decided the day.

Returns all classical conditions affecting the date:

Applies hierarchy: Eclipse → Ekadashi → Amavasya → Purnima → Bhadra → Panchak → Shool → Special Yogas. Returns AVOID / NEUTRAL / GOOD / EXCELLENT rating.

{
  "event": "marriage",
  "rating": "AVOID",
  "score": 18,
  "blocking_factors": ["Bhadra active until 15:30", "Panchak — Mritu Panchak"],
  "supporting_factors": ["Abhijit Muhurat available 11:52–12:40"],
  "hierarchy_applied": ["BHADRA", "PANCHAK"],
  "disclaimer": "Guidance is based on classical shastric rules..."
}

Given a date range and event type, returns only the GOOD and EXCELLENT rated dates sorted by score. Ideal for muhurat calendar builders.

Returns whether date falls in Panchak (5 inauspicious nakshatras: Dhanistha, Shatabhisha, Purva/Uttara Bhadrapada, Revati). Returns type (Mritu/Agni/Raja/Chora/Roga), severity, avoided activities, and specific remedies.

Bhadra is the most inauspicious Karana. Returns exact start/end time if active, and the activities to avoid (new business, haircut, auspicious ceremonies).

Checks whether the date falls in Ganda Mool nakshatras (Ashwini, Ashlesha, Magha, Jyeshtha, Mula, Revati) — considered inauspicious for birth and ceremonies.

Returns all 12 solar sankranti dates for a year with exact time, rashi transition, significance, and recommended observances.

Get detailed calendar view for a single day.

Get Panchang summary for an entire year.

Returns monthly summaries with key dates (Ekadashi, Purnima, Amavasya) and festival_count: the number of festivals /v1/festivals/month returns for that month and location (the same engine and regional rules).

Every summary is by observance, from the festival engine: an Ekadashi, Purnima or Amavasya is counted on the date it is observed, the date /v1/festivals gives (summary_basis: festival_observance).

Get Hindu month information (Amanta, Purnimanta, Saura Maasa).

Month names are machine values and stay English in every language. With a non-English lang the names in that language are added as amanta_month_local, purnimanta_month_local and saura_maasa.name_local where a translation exists; a name without one has no _local field. The paksha is returned as the engine reports it.

Get Ritu (Hindu season) for a date.

Get Samvatsara (Hindu year name) and year details.

GET /v1/timings — all auspicious and inauspicious periods for a date. Equivalent to /v1/muhurat/day. Use this for a complete timing overview.

Whether a given eclipse is visible from a location, and when.

A thin layer over the engine's own local-circumstances calculation (get_eclipse_for_date, which drives Swiss Ephemeris sol_eclipse_when_loc / lun_eclipse_how and checks that the body is actually above the horizon). No astronomy is implemented here: the same code that produces eclipse data everywhere else in the API produces it here, so the two can never disagree.

magnitude and obscuration_percent are deliberately NOT returned. The engine does not compute them, and inventing a plausible number is worse than omitting a field.

local_times are clock times in the tz offset supplied (UTC by default).

Get all eclipses for a specific year.

Get detailed eclipse information.

Generates a full Vedic birth chart. Pass the native's birth date, time, and location. Returns planetary positions in signs and nakshatras, house placements, Vimshottari Dasha periods, and notable Yogas.

curl -X POST https://api.tathaastuapi.com/v1/birth-chart \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Arjun",
    "date": "1990-05-15",
    "time": "06:30",
    "lat": 28.6139,
    "lon": 77.2090
  }'

Retrieve a previously generated birth chart by its profile ID. Returns the same full chart data without re-computing.

Provide birth details for two individuals. Returns Ashtakoot Guna score (out of 36), individual Kuta scores, Manglik Dosha analysis, Nadi Dosha check, and an overall compatibility assessment.

curl -X POST https://api.tathaastuapi.com/v1/compatibility \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "person1": {"name": "Arjun", "date": "1990-05-15", "time": "06:30", "lat": 28.6, "lon": 77.2},
    "person2": {"name": "Priya", "date": "1992-08-22", "time": "14:15", "lat": 28.6, "lon": 77.2}
  }'

Retrieve a previously computed compatibility analysis by its ID.

Full human-readable compatibility report in JSON, in the requested language (lang), and -- unless pdf=false -- the same report as a PDF: pdf_url is a signed download link (report storage, branding and retention rules of the account).

Lightweight compatibility score API.

The classical transit rule applied from your Moon sign, graha by graha, each line carrying its sloka. lang is optional: omit it for the calculation only, pass it to add rendered content.

All twelve rashis for one date. The transit chart is built once and shared, so this is far cheaper than twelve separate calls.

period_type is daily, weekly, monthly or yearly. Weeks run Monday to Sunday; months and years are calendar ones, so date is any day inside the period you want. The response separates calculation from content.

The same period reading for all twelve, sharing one transit calculation. Yearly is pre-generated, so a cold yearly request is served from cache rather than computed in the request.

The natal-chart daily reading. Unlike Rashifal it takes full birth details rather than a Moon sign, so it can use rules that need a natal chart.

PRO. A traditional, rule-based reading, not a prediction.

Every factor is a classical transit result (Phaladeepika XXVI.9-24) for a graha in a house counted from your Moon sign, admitted through TathaAstu's source and interpretation gates. Death, injury, named disease and the illness of others are never rendered. Levels are a TathaAstu presentation convention, not a classical score; health, relationship and travel carry no level. The existing /v1/rashifal/vedic/daily response is unchanged.

PRO. All twelve rashis for one date; each entry equals the single call.

Multi-religion world festival calendar. Query by date, year, month, religion, or search by name. Returns paginated results sorted by date.

# All Islamic festivals for 2025
curl "https://api.tathaastuapi.com/v1/festivals/world?year=2025&religion=islamic" \
  -H "X-API-Key: YOUR_KEY"

# Search for Eid festivals
curl "https://api.tathaastuapi.com/v1/festivals/world?search=eid&year=2025" \
  -H "X-API-Key: YOUR_KEY"

# Jewish festivals in March 2025
curl "https://api.tathaastuapi.com/v1/festivals/world?year=2025&month=3&religion=jewish" \
  -H "X-API-Key: YOUR_KEY"

{
  "total": 28,
  "limit": 100,
  "offset": 0,
  "festivals": [
    {
      "year": 2025,
      "religion": "islamic",
      "festival_id": "ramadan_start",
      "festival_name": "Ramadan Begins",
      "gregorian_date": "2025-03-01",
      "display_date": "2025-03-01",
      "day_of_week": "Saturday",
      "calendar_ref": "1 Ramadan 1446 AH",
      "notes": "Astronomical new moon calculation"
    }
  ],
  "filters": { "year": 2025, "religion": "islamic" }
}

Returns all available religions with total festival counts, unique festival types, and year coverage range. Use this to discover what data is available.

curl "https://api.tathaastuapi.com/v1/festivals/world/religions" \
  -H "X-API-Key: YOUR_KEY"

{
  "religions": [
    { "religion": "islamic", "total_festivals": 24843, "unique_festivals": 36, "min_year": 1700, "max_year": 2400 },
    { "religion": "christian", "total_festivals": 21861, "unique_festivals": 31, "min_year": 1700, "max_year": 2400 },
    { "religion": "jewish", "total_festivals": 19245, "unique_festivals": 28, "min_year": 1700, "max_year": 2400 },
    { "religion": "sikh", "total_festivals": 14700, "unique_festivals": 21, "min_year": 1700, "max_year": 2400 },
    { "religion": "orthodox", "total_festivals": 13700, "unique_festivals": 20, "min_year": 1700, "max_year": 2400 }
  ],
  "total_records": 94349,
  "year_range": { "min": 1700, "max": 2400 }
}

Returns upcoming world festivals from the current date, across all religions or filtered by a specific religion. Ideal for calendar widgets and notifications.

# Upcoming Sikh festivals
curl "https://api.tathaastuapi.com/v1/festivals/world/upcoming?religion=sikh&limit=10" \
  -H "X-API-Key: YOUR_KEY"

Returns festivals for an array of dates in one call. Supports region and language filtering. Max 365 dates per request on Enterprise.

Every language lang accepts, from the language registry.

This used to list the distinct languages present in one vocabulary table, which could disagree with the languages the API actually accepts, and it said every translation was a phonetic transliteration, which is not true.

Get transliteration strings for a category and language.

Four routes serving the classical transit rule counted from your Moon sign, with the sloka on every line. Weekly, monthly and yearly are the same per-day verdict reported over a date range — not a separate methodology. One rashi or all twelve; en or hi; today and tomorrow resolved against Asia/Kolkata. There is no overall score, ranking or lucky number, because Phaladeepika XXVI establishes none — see Rashifal & Daily Jyotish ↓.

Four new calculation APIs for the Kota, Saptaśalāka, Sarvatobhadra and Śūla chakras, each returning rule-level provenance and verification metadata.

Available on the free plan. These calls are included within your existing free-plan monthly quota — authenticated and counted like any other endpoint, not unmetered.

Pre-resolved inputs. These endpoints take nakshatra values you have already resolved. They do not calculate planetary positions from birth date, time or location.

Calculation only. Every response carries "calculation_only": true. Each rule reports its own verification level rather than the chakra carrying a single badge, and where sources differ, the reading used is named in the response.

See Chakra Calculation APIs ↓ for full documentation.

Key creation, rotation and regeneration now always produce sk_live_ keys. TathaAstu has no sandbox environment: every key reaches production endpoints and consumes your plan quota.

Existing keys are unaffected. Nothing has been revoked or regenerated. A key created earlier with a different prefix continues to work exactly as before, and converts to sk_live_ the next time you rotate or regenerate it.

1. Overview. The Kota chakra arranges 28 nakshatras as a four-ringed fort around the janma nakshatra. This endpoint reports which ring (zone) a transiting nakshatra occupies and whether it lies on an inbound (ENTRY) or outbound (EXIT) route, plus the fort's lord and guard.

2. Endpoint. GET /v1/chakra/kota

3. Inputs.

4. Output. ordinal_from_janma (1–28), zone (STAMBHA · DURGANTARA · PRAAKAARA · BAHYA), path and effective_path (ENTRY/EXIT after motion reversal), path_reversed, kota_swami, kota_pala, and a summary.

5. Example request.

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.tathaastuapi.com/v1/chakra/kota?janma_nakshatra=Krittika&transit_nakshatra=Rohini&moon_rashi=Taurus"

6. Example response.

{
  "chakra": "KOTA",
  "calculation_only": true, "interpretation": false,
  "inputs_are_pre_resolved": true,
  "result": {
    "janma_nakshatra": "Krittika",
    "kota_swami": "Venus",
    "kota_pala": "Sun",
    "transits": [{
      "planet": "Saturn", "nakshatra": "Rohini",
      "ordinal_from_janma": 2, "zone": "PRAAKAARA",
      "path": "ENTRY", "motion": "DIRECT",
      "effective_path": "ENTRY", "path_reversed": false
    }],
    "summary": { "total": 1, "on_entry_path": 1, "on_exit_path": 0, "in_stambha": 0 }
  },
  "ruleset": {
    "pala_variant": "PALA_NAKSHATRA_LORD",
    "verification": {
      "zones": "CROSS_VERIFIED_SECONDARY",
      "entry_exit": "DERIVED_FROM_DIAGRAM_SECONDARY",
      "kota_pala": "PROVISIONAL_DISPUTED"
    }
  }
}

7. Verification / provenance. Zone membership is CROSS_VERIFIED: two sources sharing no text agree on all 28 placements. Entry/exit is DERIVED from a labelled source diagram. Motion reversal and Kota Svāmī are corroborated by three sources with no dissent.

8. Scope and limitations. No interpretation of what a zone or path implies. Kota Svāmī is null rather than guessed when moon_rashi is omitted, because a nakshatra can straddle two rāśis. Abhijit's longitude arc is not resolved here.

1. Overview. Seven horizontal and seven vertical lines carry the 28 nakshatras at their ends, walking clockwise from the North-East beginning at Kṛttikā. The two nakshatras at opposite ends of a line are vedha to each other — fourteen mutual pairs.

2. Endpoint. GET /v1/chakra/saptashalaka

3. Inputs.

4. Output. The vedha_partner with its position (1–28 from Kṛttikā) and whether the line is HORIZONTAL or VERTICAL; optionally the Sun comparison.

5. Example request.

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.tathaastuapi.com/v1/chakra/saptashalaka?nakshatra=Krittika&sun_nakshatra=Shravana"

6. Example response.

{
  "chakra": "SAPTASHALAKA",
  "calculation_only": true, "interpretation": false,
  "result": {
    "janma": { "position": 1, "nakshatra": "Krittika" },
    "vedha_partner": { "position": 21, "nakshatra": "Shravana", "line": "HORIZONTAL" },
    "sun": { "nakshatra": "Shravana", "is_vedha_to_janma": true }
  },
  "ruleset": {
    "construction": "7_HORIZONTAL_7_VERTICAL_28_ENDPOINTS",
    "vedha_rule": "OPPOSITE_ENDS_OF_THE_SAME_LINE",
    "pair_count": 14,
    "verification": "DIAGRAM_VERIFIED_SECONDARY"
  }
}

7. Verification / provenance. DIAGRAM_VERIFIED_SECONDARY. The construction is stated in prose, but the fourteen pairs exist in the source only as a diagram, which was read directly. Three checks passed: the one pair the prose does state (Kṛttikā ↔ Śravaṇa) is reproduced; every nakshatra appears exactly once; and 14 lines × 2 ends = 28. Independently, this pairing agrees with the Sarvatobhadra opposition relation on all 28 stars, from an unrelated source.

8. Scope and limitations. Returns the pairing only. The classical application concerns danger to life; no such reading is returned. Whether the pairing is motion-sensitive is not stated by the source and is therefore not modelled.

1. Overview. A 9×9 lattice of 81 cells: 28 nakshatras on the outer ring, then 20 consonants, 12 rāśis, five tithi groups at the centre, and 16 vowels on the ring corners. A graha strikes cells along three lines.

2. Endpoint. GET /v1/chakra/sarvatobhadra

3. Inputs.

4. Output. For each of OPPOSITE, FORWARD and BACKWARD: the ordered list of struck cells with row, column, kind and label, plus the border star at the end of the line and whether that direction is dominant.

5. Example request.

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.tathaastuapi.com/v1/chakra/sarvatobhadra?nakshatra=Krittika&planet=Mars"

6. Example response (cells abridged).

{
  "chakra": "SARVATOBHADRA",
  "calculation_only": true, "interpretation": false,
  "result": {
    "transits": [{
      "planet": "Mars", "nakshatra": "Krittika",
      "motion": "DIRECT", "dignity": "NORMAL",
      "strength_multiplier": 1.0,
      "dominant_direction": "FORWARD",
      "vedha": {
        "OPPOSITE": { "struck_star": "Shravana", "is_dominant": false, "cells": [ "..." ] },
        "FORWARD":  { "struck_star": "Vishakha", "is_dominant": true,  "cells": [ "..." ] },
        "BACKWARD": { "struck_star": "Bharani",  "is_dominant": false, "cells": [ "..." ] }
      }
    }]
  },
  "ruleset": {
    "rules": {
      "lattice": "VERIFIED", "vedha_geometry": "VERIFIED",
      "rasi_placement": "VERIFIED", "consonant_placement": "DERIVED",
      "vowel_placement": "DERIVED", "tithi_placement": "DERIVED",
      "abhijit_resolution": "UNRESOLVED", "motion_strength": "VARIANT",
      "junction_rules": "NOT_IMPLEMENTED", "interpretation": "EXCLUDED"
    }
  }
}

7. Verification / provenance. The lattice and vedha geometry are VERIFIED against 12 published known-value vectors (four stars × three directions) and all 16 cells of a published worked example. Rāśi placement is VERIFIED — the rule is explicit in the source. Consonant, vowel and tithi placement are DERIVED: the sources give those sets but defer placement to their diagrams, so a stated interpretation was fixed in advance and then reproduced the worked example exactly. That corroborates the reading without being the text settling it.

8. Scope and limitations. Motion is returned as a dominance marker and a strength multiplier, not as a filter — sources conflict on whether all three lines act or motion selects one, so both readings ship and neither is presented as correct. Three further rules are declared NOT_IMPLEMENTED rather than guessed: the junction/pada rule, paired-letter coupling, and the uncovered-consonant triplets. No interpretation is returned.

1. Overview. A trident laid over the 28-fold Sarvatobhadra framework. The reference nakshatra is the base of the staff; the three spear tips fall at the 9th (direct trine), the 15th (exactly opposite) and the 21st (reverse trine).

2. Endpoint. GET /v1/chakra/shoola

3. Inputs.

4. Output. The four shoola_points with their ordinals and nakshatra names, the reference body used, and each transit reported as a hit or not.

5. Example request.

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.tathaastuapi.com/v1/chakra/shoola?reference_nakshatra=Ashwini&transit_nakshatra=Anuradha"

6. Example response.

{
  "chakra": "SHOOLA",
  "calculation_only": true, "interpretation": false,
  "result": {
    "reference": { "body": "SUN_NAKSHATRA", "nakshatra": "Ashwini" },
    "shoola_points": [
      { "position": 1, "ordinal": 1,  "nakshatra": "Ashwini" },
      { "position": 2, "ordinal": 9,  "nakshatra": "Ashlesha" },
      { "position": 3, "ordinal": 15, "nakshatra": "Swati" },
      { "position": 4, "ordinal": 21, "nakshatra": "U.Ashadha" }
    ],
    "transits": [{ "planet": "Saturn", "nakshatra": "Anuradha", "hit": false }]
  },
  "ruleset": {
    "variant": "SUN_4POINT",
    "reference": "SUN_NAKSHATRA",
    "nakshatra_scheme": "28_WITH_ABHIJIT",
    "framework": "SARVATOBHADRA_28",
    "verification": "SOURCED_NAMED_AUTHOR"
  }
}

7. Verification / provenance. SUN_4POINT is the sourced reading: a named author's dedicated chapter states that the Sun's nakshatra is the base of the staff and gives the tips as the 9th direct, the 15th opposite and the 9th reverse, presenting these as classical and traditional. The same source places the chakra on the 28-fold framework — which is what makes the rule self-consistent, since the 15th is "exactly opposite" only in a 28-fold cycle.

8. Scope and limitations. The sources use this chakra to judge illness, accidents and death. No such reading is returned, and none should be inferred from a "hit". The API reports only which nakshatras are śūla points and whether a supplied transit occupies one.

Reference list. These endpoints take pre-resolved nakshatra names; this is the accepted vocabulary, Abhijit included.

Get detailed Karana information for a date.

Get special yogas (Sarvartha Siddhi, Amrita Siddhi, Dwipushkar, Tripushkar).

Get detailed Yoga information for a date.

The Bhinnashtakavarga of the seven grahas and the Lagna, with the contributors of every point; the Samudaya with its favourable / middling / difficult bands; and Trikona and Ekadhipatya reduction with Rashi, Graha and Yoga Pinda. The point table is decoded from the karana verses of BPHS 66 and checked against their counts, the fixed totals and Santhanam's worked example. Ekadhipatya reduction is read differently by the editions; all three readings are returned and the primary one is named.

Evaluates the birth moment against BPHS ch. 85-96: Amāvasyā, the six parts of Kṛṣṇa Caturdaśī, Viṣṭi karaṇa, Vyatīpāta yoga, a kṣaya tithi, tithi / nakṣatra / lagna Gaṇḍānta, Abhukta Mūla, saṅkrānti and solar or lunar eclipse, with the junction times and the Sanskrit verse for each. Family nakṣatra and birth-order conditions are evaluated only when supplied. Names the text lists but does not define (Yamaghaṇṭa, Dagdha yoga, Pāta) are listed as not computed. Remedies are returned as text, not advice.

The avasthas of BPHS ch. 45 for every graha: Baladi, Jagradadi, Deeptadi, Lajjitadi and Shayanadi with Drishti / Cheshta / Vicheshta, together with the natural, temporary and compound relationships of ch. 3 they depend on. Every state carries its verse. Where the Pathak edition, the transcription and Santhanam's translation read a rule differently, each reading is returned; the effect verses are returned as text, not as a prediction.

Kuja (Mangal) dosha from BPHS 80.47-49 and Phaladeepika XI.3, and the serpent's and father's curse yogas of BPHS ch. 83 judged by the Sanskrit text, each with its verse. Where R. Santhanam's translation reads a verse differently, that reading is evaluated and returned beside the verdict. Conditions the text does not let a chart decide (strength without a stated threshold, Gulika) are returned as null, never guessed. Kaal Sarp and Sade Sati have no classical locus; they are returned under conventions.

Complete Vedic calculation from one canonical chart. The response is {data, meta}; data holds: birth (the input as used, with Julian day), calculation (ayanamsa, node, house system, ephemeris and versions used), lagna, planets (9 grahas: sign, degree, house, nakshatra and pada, lords, retrograde, dignity, speed, navamsa sign), houses (whole-sign houses with Placidus cusps alongside), vargas and varga_metadata (all 16 Parashari divisional charts, D1 to D60, each with its rule and source), dashas (Vimshottari: balance at birth; current = the periods running at the moment of birth, not today; the full mahadasha > antardasha > pratyantardasha timeline; dasha_levels 1-3), karakas (Chara karakas), special_lagnas (Arudha, Upapada, Badhaka, Maraka, Gulika/Mandi), aspects (Parashari graha drishti), dispositors, planetary_relationships (combustion, planetary war), planetary_nature (natural and functional) and argala. include_yogas=true adds the legacy yoga list; include_shadbala=true adds Shadbala. Every response echoes the exact calculation conventions used. /v1/birth-chart (the older, flatter chart) is unchanged and remains available.

The Birth Report generated from the frozen Calculation Engine (calculation 1.2.0).

edition=predictive (default): birth chart and D9, personality, life areas (career, finance, marriage, family, children, education, property, health, spiritual, travel), current and next mahadasha, a year-by-year outlook (forecast_years, 1-20, default 10, from the current calendar year) from Jupiter/Saturn/Rahu/Ketu transits, a lifetime view of every mahadasha, and the sources used. edition=calculation: the chart, every table and the traditional interpretation, without predictions.

Returns a signed PDF link (report storage, branding and retention rules of the account). English and Hindi text is authored; the other languages are translations pending native review, and the report says so.

Free teaser preview of the Kundli report. Returns: Lagna, Moon sign, 2 key insights. The full report is POST /v1/kundli/birth-report.

The five aprakāśa grahas (Dhūma, Vyatīpāta, Pariveṣa, Indracāpa, Upaketu) from BPHS ch. 3 and the five kālavelās (Kāla, Mṛtyu, Ardhaprahara, Yamaghaṇṭaka, Gulika) from BPHS ch. 4, each with its Sanskrit verse from the Pathak edition and R. Santhanam's translation. Kālavelās are counted from the vāra that began at the sunrise before the birth, and the longitude rising at the start and at the end of each part are both returned. Above the polar circles on days without sunrise or sunset the kālavelās are reported unavailable.

Get list of predefined locations with coordinates.

gn:<geonames id>, or a bare numeric id.

Deliberately not /v1/locations/{id}: that path already belongs to the 27 predefined locations and customers hold those ids, so taking it over would change what an existing call returns.

Search places by name, with administrative filtering

Get details for a specific location.

Government holidays for one region and year, with their sources.

Returns only what a government notification attests. Where a notification has not been obtained, coverage.status says PARTIAL or NOT_OBTAINED and the list is short on purpose — it is never padded from news reports or another state's calendar.

Rows that rest on a copy of a notification that was not read on a government host are provisional. They are left out unless you ask for them with include=provisional, and they are flagged when returned.

How far this year's data is attested, subject by subject.

A subject is COMPLETE only when its base notification was read on a government host and no verification item is open against it.

Every region this dataset covers, with its aliases.

The ISO 3166-2 code is the identity. Short codes ('MH') and codes a region used to carry ('IN-OR' for Odisha, 'IN-TG' for Telangana) are aliases that resolve to it, and never the other way round.

The notifications a region's year rests on, in the order they were issued.

PRO. One call, from the date of birth.

Numbers (MODERN_NUMEROLOGY, not classical Jyotish). birth_number (Mulank) is the day of the month reduced to one digit; destiny_number (Bhagyank) is every digit of the date reduced to one digit; lucky_number is the birth number. Each number's planet comes from Cheiro's table (*Book of Numbers*, pp. 33-34) with Rahu and Ketu in place of Uranus and Neptune. No classical Jyotish work assigns lucky numbers, and the response says so.

Colours and gems. Each number carries its planet's classical colour (Phaladeepika II.8-14, II.33-34) and gem (Phaladeepika II.29), as REFERENCE_ONLY. lucky_colour is the colour of the lucky number's planet, a labelled PRODUCT_CONVENTION. Given time_of_birth, latitude and longitude, chart_gem_reference adds the rulers of the lagna and Moon sign of the canonical Vedic chart and their gems; choosing a stone that way is modern practice and is labelled so. The classical texts that use gems in remedies give them away in donation, not wear them. Nothing here recommends wearing or buying a gemstone, and no benefit is claimed. Never intended for gambling, lotteries or betting.

A classical reading, not a prediction. Form: Bṛhat Jātaka 5.23 (repeated by Phaladīpikā XVI.1 and Jātaka Pārijāta III.76) teaches that the body resembles the lord of the navāṁśa rising at birth; that planet's described form is returned (BJ 2.8-2.11). Lagna sign features (Phaladīpikā IX) and Moon sign features (Bṛhat Jātaka 17) are returned side by side, and planets in the 1st house add the texts' bodily clauses. Every item cites book and verse; points where the texts disagree are listed under texts_differ, and what the texts leave undefined (the strongest planet, complexion, height) is not computed.

A classical reading, not a prediction. Moon sign: Bṛhat Jātaka 17 (with Sārāvalī 23 as a second witness); lagna: Phaladīpikā IX. Only temperament traits are served, each with its verse; clauses about wealth, family, health or events (predictions) and abusive wording are withheld and only counted. Unflattering classical traits are served with tone: unfavourable. Where the texts or translators disagree it is listed under texts_differ.

A classical reading, not a prediction. Bṛhat Jātaka 25.14 associates the lord of the drekkāṇa held by the stronger luminary with the world a soul is said to come from (Jupiter: gods; Moon/Venus: ancestors; Sun/Mars: tiryak; Saturn/Mercury: infernal), and 25.15 gives the world it is said to go to and the mokṣa yoga. The text does not define the stronger luminary, so the Sun- and Moon-based results are both returned and selected is set only when they agree. Every item cites book and verse.

A classical reading, not a prediction. The texts are one-way: Bṛhat Jātaka 24.11-12 (with Sārāvalī 45.21-24) describes the husband, from a woman's chart, by the lord of the 7th sign or of the 7th navāṁśa sign; single conditions in Sārāvalī, Phaladīpikā and BPHS describe the wife, from a man's chart. Every statement keeps that frame; gender is never inferred (use frame to filter). Derogatory verdicts, timing and loss of marriage are not served; where the two lords differ both are returned and none is selected.

Creates or reuses an immutable, compressed annual calendar for one calculation-ready location, one year and one language: every date with Panchang, sunrise/sunset, moonrise/moonset, festivals, observances, Hora, Choghadiya, Muhurat (incl. durmuhurta, varjyam, amrit kaal), Hindu calendar, conditions and eclipse. 202 while it builds, 200 when ready; poll the returned link or subscribe to the calendar.dataset.ready webhook. Enterprise plan.

List this account's Annual Calendar Dataset requests

Annual Calendar Dataset: what this account may request

Annual Calendar Dataset status and download

Cancel a queued Annual Calendar Dataset request

The file a READY dataset's download.url points to. No API key: the link itself is the credential, valid for 2 hours and only for the account and request it was issued for.

The file a READY dataset's download.url points to. No API key: the link itself is the credential, valid for 2 hours and only for the account and request it was issued for.

The file a READY dataset's download.url points to. No API key: the link itself is the credential, valid for 2 hours and only for the account and request it was issued for.

A versioned, signed-download copy of the gazetteer behind /v1/locations/search for one country, optionally one state and one place type: stable ids (gn:<geonames id>), names, administrative hierarchy, coordinates and their precision, IANA timezone, confidence and ambiguity, GeoNames attribution (CC BY 4.0). Only places linked to a curated /v1/locations id are calculation_ready. 202 while it builds, 200 when ready. Enterprise plan.

List this account's Location Catalogue requests