Products

Eight API surfaces, one engine

Every product below reads from the same astronomy layer and the same versioned rule set. Mixing them in one application never produces two contradictory answers.

Panchang API Festival API Muhurat API Astronomy API Calendar API Webhook Platform Enterprise APIs Chakra Calculation APIs Government Holidays API

Panchang API

The five limbs of the Hindu calendar — tithi, nakshatra, yoga, karana and vara — for any date and location, with the interval boundaries rather than just the label at sunrise.

Independently compared with Government of India PAC / Rashtriya Panchang reference data. See the validation.

The problem it solves

Most calendar APIs return the tithi that happened to be running at sunrise. That is fine until a user asks why their app disagrees with the temple, which is almost always because the tithi changed at 11:28 that morning.

Use cases

Daily panchang screens in calendar and devotional apps
Server-side scheduling that must respect tithi boundaries
Almanac and print calendar generation

Typical customers

Calendar appsDevotional platformsPublishers

Key endpoints

Method	Path	Purpose
GET	/v1/panchang	Full day, all five limbs
GET	/v1/panchang/lite	Reduced payload for list views
GET	/v1/panchang/today	Convenience wrapper
GET	/v1/tithi	Tithi with start and end instants
GET	/v1/nakshatra	Nakshatra intervals
GET	/v1/yoga	Yoga intervals
GET	/v1/karana	Karana intervals
GET	/v1/panchang/range	Date range in one call

Documentation Try it in the playground

Panchang API — sample response

{
  "date": "2026-03-01",
  "tithi": {
    "num": 14,
    "name": "चतुर्दशी",
    "paksha": "KRISHNA",
    "starts_at": "2026-02-28T18:04:11+05:30",
    "ends_at": "2026-03-01T14:22:08+05:30"
  },
  "nakshatra": { "name": "स्वाति", "ends_at": "2026-03-01T09:47:52+05:30" },
  "vara": "Sunday",
  "sunrise": "06:47:12", "sunset": "18:31:44"
}

Festival API

Festivals derived at request time from versioned rules, each returned with the derivation that produced it — the rule, the authority, the overlap in minutes, and the confidence.

The problem it solves

Hardcoded festival tables go stale and cannot explain themselves. When a date is disputed you need to show the reasoning, not a row in a spreadsheet.

Use cases

Festival calendars that must survive a rule correction
Notification scheduling with a defensible date
Editorial and content pipelines needing provenance

Typical customers

Temple platformsMediaHR systems

Key endpoints

Method	Path	Purpose
GET	/v1/festivals	Festivals for a date or window
GET	/v1/festivals/explain	Full evaluation trace
GET	/v1/festivals/year	Whole-year sweep
GET	/v1/festivals/month	Calendar month
GET	/v1/festivals/range	Arbitrary window
GET	/v1/festivals/search	Find by name
GET	/v1/vrat	Fasting observances
GET	/v1/festivals/world	Multi-religion calendar

Documentation Try it in the playground

Festival API — sample response

{
  "festival": "FESTIVAL_DIWALI",
  "selected_date": "2026-11-08",
  "confidence": 100,
  "confidence_label": "FULL_KALA_COVERAGE",
  "explain": {
    "evaluator": "PRADOSHA_VYAPINI",
    "rule_code": "DIWALI_V2",
    "rule_version": 2,
    "overlap_minutes": { "2026-11-08": 96, "2026-11-09": 0 },
    "reason": "Amavasya fully covers Pradosha on Nov 8",
    "authority": ["Dharmasindhu", "Nirnaya Sindhu"]
  }
}

Muhurat API

Auspicious and inauspicious windows computed from the same kala arithmetic the festival engine uses — abhijit, brahma muhurta, rahu kalam, yamaganda, gulika, choghadiya and hora.

The problem it solves

Muhurat windows are frequently published as fixed clock times. They are not fixed: every window is a fraction of the local day length, so they move with latitude and season.

Use cases

Wedding and event date selection
Travel departure timing
Trading and business-hours advisories

Typical customers

Wedding platformsTravelMatrimony

Key endpoints

Method	Path	Purpose
GET	/v1/muhurat/day	All windows for a day
GET	/v1/muhurat/find	Search for a suitable window
GET	/v1/abhijit	Midday muhurta
GET	/v1/rahukaal	Rahu kalam
GET	/v1/yamaganda	Yamaganda
GET	/v1/gulikaal	Gulika kalam
GET	/v1/choghadiya	Choghadiya segments
GET	/v1/hora	Planetary hours

Documentation Try it in the playground

Muhurat API — sample response

{
  "date": "2026-03-01",
  "abhijit": {
    "start": "11:52:31", "end": "12:42:07",
    "available": true,
    "overlaps": []
  },
  "brahma_muhurta": { "start": "04:46:12", "end": "05:30:44" },
  "rahu_kalam": { "start": "16:42:00", "end": "18:10:00" }
}

Astronomy API

The Swiss Ephemeris layer exposed directly — sidereal positions, sankranti instants, eclipse circumstances, moon phase and lagna.

The problem it solves

Sometimes you need the astronomy, not the calendar interpretation of it. Rather than make you reimplement the ephemeris, we expose the layer the rest of the platform is built on.

Use cases

Research and archival calculation
Astronomy features in education apps
Cross-checking a third-party calculation

Typical customers

EducationResearchPublishers

Key endpoints

Method	Path	Purpose
GET	/v1/astronomical	Planetary positions
GET	/v1/sankranti	Solar ingress instants
GET	/v1/eclipse	Eclipse circumstances
GET	/v1/eclipse/visibility	Local visibility
GET	/v1/moon-phase	Phase and illumination
GET	/v1/lagna	Ascendant
GET	/v1/sun	Sunrise, sunset, transit

Documentation Try it in the playground

Astronomy API — sample response

{
  "date": "2026-03-01",
  "ayanamsa": { "system": "LAHIRI", "value": 24.2118 },
  "sun":  { "sidereal_longitude": 317.4402, "rashi": "Kumbha" },
  "moon": { "sidereal_longitude": 191.8875, "rashi": "Tula" }
}

Calendar API

Month, year and range views that combine panchang, festivals and muhurat into the shape a calendar UI actually needs — one call per screen, not one per day.

The problem it solves

Rendering a month view by calling a per-day endpoint thirty times is slow and wasteful. These endpoints return the whole grid in a single response.

Use cases

Month-view calendar rendering
Year planners and printable almanacs
Bulk export into an existing scheduling system

Typical customers

Calendar appsERPPublishing

Key endpoints

Method	Path	Purpose
GET	/v1/calendar/month	Full month grid
GET	/v1/calendar/year	Year overview
GET	/v1/calendar/range	Arbitrary window
GET	/v1/calendar/day	Single day, combined
GET	/v1/hindu-month	Amanta / purnimanta month
GET	/v1/samvatsara	Samvatsara name and year
GET	/v1/ritu	Season

Documentation Try it in the playground

Calendar API — sample response

{
  "year": 2026, "month": 11, "location_id": 1,
  "days": [
    { "date": "2026-11-08",
      "tithi": "Amavasya",
      "festivals": ["FESTIVAL_DIWALI"],
      "is_holiday": true }
  ],
  "_engine": { "festival_engine": "v2.0.0", "rule_pack": "NORTH_INDIA" }
}

Webhook Platform

HMAC-signed event delivery for festival and muhurat events, with exponential backoff and explicit idempotency semantics.

The problem it solves

Polling a calendar API every morning to find out whether today is a festival is wasteful and fragile. Events should arrive.

Use cases

Push notifications ahead of a festival
Triggering downstream jobs on calendar events
Keeping a local cache in sync

Typical customers

Mobile appsHR systemsNotification platforms

Key endpoints

Method	Path	Purpose
POST	/v1/webhooks/subscribe	Create a subscription
GET	/v1/webhooks/events	Delivery history

Documentation Try it in the playground

Webhook Platform — sample response

POST https://your-app.example/hooks
X-TathaAstu-Event-Id: evt_01JQ8Z...
X-TathaAstu-Signature: sha256=9f86d0818...

{
  "event": "festival.upcoming",
  "festival": "FESTIVAL_DIWALI",
  "date": "2026-11-08",
  "lead_days": 7
}

Enterprise APIs

Bulk endpoints, custom locations, custom rule packs, and the operational commitments that procurement asks for.

The problem it solves

A platform serving millions of users needs different primitives from a hobby project: batch calls, dedicated capacity, and a contact who answers.

Use cases

Precomputing a year for millions of users
Onboarding cities outside the default set
Authoring a regional rule pack for your community

Typical customers

Large platformsGovernmentEnterprise ERP

Key endpoints

Method	Path	Purpose
POST	/v1/bulk/panchang	Batch panchang
POST	/v1/bulk/festivals	Batch festivals
GET	/v1/day-context/range	Raw day context
GET	/v1/shastra/conditions	Rule conditions

Documentation Try it in the playground

Enterprise APIs — sample response

POST /v1/bulk/panchang
{
  "location_id": 1,
  "dates": ["2026-11-08", "2026-11-09", "2026-11-10"],
  "fields": ["tithi", "nakshatra", "festivals"]
}

Chakra Calculation APIs

Kota, Saptashalaka, Sarvatobhadra and Shula chakras as pure calculation endpoints, each response carrying the ruleset and a verification level for every individual rule. Available on the Free tier, included within the existing Free-plan monthly quota.

The problem it solves

Chakra implementations rarely say where their rules come from, and the sources genuinely disagree in places. An API that flattens that into one confident answer is hiding the part a serious developer needs. These endpoints report per-rule provenance, name the reading used wherever sources conflict, and return calculation only.

Use cases

Transit dashboards that show the chakra structure rather than a verdict
Research and teaching tools that need the rule and its source alongside the result
Existing astrology products adding chakra views without building the geometry

Typical customers

Astrology platformsResearch and teaching toolsPanchang apps

Key endpoints

Method	Path	Purpose
GET	/v1/chakra/kota	Zone, entry/exit path, Swami and Pala
GET	/v1/chakra/saptashalaka	Nakshatra vedha pairing
GET	/v1/chakra/sarvatobhadra	Three vedha lines over the 81-cell lattice
GET	/v1/chakra/shoola	Trident points on the 28-fold cycle
GET	/v1/chakra/nakshatras	Accepted 28-fold vocabulary

Documentation Try it in the playground

Chakra Calculation APIs — sample response

GET /v1/chakra/sarvatobhadra?nakshatra=Krittika
{
  "chakra": "SARVATOBHADRA",
  "calculation_only": true,
  "interpretation": false,
  "inputs_are_pre_resolved": true,
  "result": {
    "transits": [{
      "nakshatra": "Krittika",
      "vedha": {
        "OPPOSITE": { "struck_star": "Shravana" },
        "FORWARD":  { "struck_star": "Vishakha" },
        "BACKWARD": { "struck_star": "Bharani" }
      }
    }]
  },
  "ruleset": {
    "rules": {
      "lattice": "VERIFIED",
      "vedha_geometry": "VERIFIED",
      "consonant_placement": "DERIVED",
      "abhijit_resolution": "UNRESOLVED",
      "interpretation": "EXCLUDED"
    }
  }
}

Government Holidays API

Civil government holiday calendars for the Indian states, union territories and the Central Government, where every date carries the notification it came from — the issuing authority, its number and date, and the document it was read in. 2026 is published; each response reports how far that region’s year is attested.

The problem it solves

Holiday lists are usually copied from a news article once a year, which hides three things that matter. States amend dates mid-year: Id-ul-Zuha moved from 27 to 28 May 2026 in several states, by notification. Office, bank, restricted and local lists are different lists, and a bank in Odisha does not close on the same days as a state office. And a government holiday is a civil fact, not a religious one — this data never decides or moves a festival date, which the Festival Engine keeps doing from the Panchang.

Use cases

Payroll and HR leave calendars that differ by state
Banking and settlement calendars, which follow their own notified list
Logistics, SLA and delivery-date planning across states
Reconstructing what a calendar said before an amendment, with as_of

Typical customers

HR and payroll platformsBanking and fintechLogisticsERP

Key endpoints

Method	Path	Purpose
GET	/v1/government-holidays	One region and year, with sources
GET	/v1/government-holidays/regions	Regions covered, with aliases
GET	/v1/government-holidays/coverage	How far each region is attested
GET	/v1/government-holidays/sources	The notifications a year rests on

Documentation Try it in the playground

Government Holidays API — sample response

GET /v1/government-holidays?region=IN-OD&year=2026&category=PUBLIC
{
  "region": { "code": "IN-OD", "name": "Odisha", "type": "STATE" },
  "year": 2026,
  "coverage": { "status": "COMPLETE", "source_evidence": "OFFICIAL" },
  "holidays": [{
    "date": "2026-05-28",
    "name": "Id-ul-Zuha",
    "canonical_class": "PUBLIC",
    "applies_to": [
      { "audience": "STATE_GOVERNMENT_OFFICES", "scope": "WHOLE_REGION" },
      { "audience": "COURTS", "scope": "WHOLE_REGION" }
    ],
    "amends": { "date": "2026-05-27" },
    "source": {
      "authority": "Revenue and Disaster Management Department",
      "notification_number": "RDM-Reg-MISC-0021-2025-21787/Revenue",
      "notification_date": "2026-05-25",
      "evidence_grade": "OFFICIAL"
    }
  }]
}

All 136 endpoints, one spec

The complete OpenAPI 3.1 document describes every endpoint, parameter and response shape on this page. Import it into Postman, or generate a client in your language.

Read the API reference Developer quickstart