---
title: "Muhurat Top10 Endpoint"
method: POST
path: "/muhurat/top10"
---

# Muhurat Top10 Endpoint

`POST /muhurat/top10`

## Request

- Base URL: `https://jyotish-api.bda.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://jyotish-api.bda.ai/muhurat/top10`
- Auth: none declared

Top-10 auspicious DATES over the next ~3 months — CACHED (issue #773).

Same deterministic engine as `/muhurat/electional` (universal classical
Choghadiya + Abhijit, minus the Rahu/Yamaganda/Gulika malefic windows; no
activity-specific ruling asserted — §8.3), aggregated to the best window per
DATE and ranked. The 90-day scan costs ~10.6s CPU per 30 days, so the result
is served from `muhurat_cache` — one compute per (11 km location bucket,
start date) per 24h, shared by every user in that bucket — instead of once
per dashboard load. This is why the packet is NOT part of the dashboard
bundle: the dashboard JS fetches it asynchronously after its own binds, so a
cold miss can never delay the board render.

Per-day compute goes through the audited `_dashboard_daily_panchang` memo
(same wrapper as `/muhurat/electional`), so an overlapping "today" compute
is shared and the read-only consumption cannot mutate the canonical cache.

`start_date` is optional and REJECTED (422) outside [today-1, today+31] in
the resolved timezone: it is part of the cache key, so an unbounded value
would let a caller sweep it and turn every request back into a cold scan.
Rejecting rather than clamping keeps the response honest about the range it
actually computed.

DARK by default (owner ruling 2026-08-20, PANDIT_RATIFICATION_PACK Section
I): with `BDA_MUHURAT_TOP10_ENABLED` unset/false this returns a clean
`feature_disabled` envelope with ZERO compute — no timezone resolve, no
cache touch, no astronomical core. It is a 200 with an empty `top_dates` rather than
a 404 on purpose: the dashboard treats a non-OK status as a TRANSPORT
failure and retries it on every re-bind (AUDIT D3-R), whereas an empty
answer is memoised, so the card settles into its locked/missing state and
stops asking. Machine-readable `enabled: false` lets an ops probe tell
"dark" apart from "broken".

## Request body

- MuhuratTop10Request
  - `lat` number, required
  - `lng` number, required
  - `tz` string, nullable: IANA timezone (auto-resolved from lat/lng if omitted)
  - `start_date` string, date, nullable: First local date to scan (YYYY-MM-DD). Defaults to today in the resolved timezone; must be within [today-1, today+31] there.
  - `days` integer: Days to scan from start_date (max ~3 months)

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/bda/apis/bda-jyotish-panchang-service.md) · [All operations](https://skmtc.dev/bda/apis/bda-jyotish-panchang-service/llms.txt) · [OpenAPI document](https://skmtc.dev/bda/apis/bda-jyotish-panchang-service/revisions/90f241bf4009?raw)