curl -X POST https://yogataraapi.prahlad.app/api/vrat-upavas/ \
-H "X-API-Key: $OCCULT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"year":2026,"month":9,"keys":["ekadashi","amavasya","pradosham"]}'Vrat and upavas are the recurring fasting and observance days of the Hindu month, each tied to a particular tithi. This endpoint returns every occurrence of the types you ask for across a whole year, read from a precomputed table rather than calculated on the request, so a year of eighteen observance types is one indexed query. Each type is defined purely by which tithi numbers it matches, in the 1-30 scheme where 1-15 are Shukla Pratipada to Purnima, 16-29 are Krishna Pratipada to Chaturdashi and 30 is Amavasya. So `ekadashi` returns both Ekadashis of every month, `pradosham` both Trayodashis, `shivarathri` the Krishna Chaturdashi of every month (the monthly Masik Shivaratri, not only Maha Shivaratri), `sashti` and `durgashtami` and `vinayaka_chathurthi` the Shukla sixth, eighth and fourth, `kaalashtami` and `sankatahara_chathurthi` their Krishna counterparts, `amavasya` and `pournami` the new and full Moons, `sathyanarayana_puja` the full Moon, `chandra_dharshan` and `moondraam_pirai` the first and third days of the waxing Moon, and `srartha_yoga`, `ashtaka`, `manvaadhi` and `yugadhi` their own small sets of tithis. Be aware that `mahalaya_paksha` matches every tithi from 15 to 30, which means the whole dark fortnight of every lunar month rather than just the Bhadrapada Pitru Paksha. `year` and `keys` are required. Passing `latitude`, `longitude` and `timezone_as_float` as well adds two live-computed fields to each event: `moonrise`, the evening moonrise falling inside that event's tithi window at your location, and, for `vinayaka_chathurthi` rows only, `puja_muhurat` with `start`, `end` and `duration_minutes` for the Madhyahna Ganesha Puja window. Both come back null if they cannot be computed, and neither is present at all if you omit the coordinates. The response is `{data}` keyed by each requested type, each holding a chronological list of `{date, month, tithi, paksha, start_time, end_time}` where the times are the exact instants the tithi begins and ends. Dates are precomputed for 2006 to 2046 inclusive; a year outside that range returns empty lists rather than an error.
| Field | Type | Required | Notes |
|---|---|---|---|
| keys | array | required | Which calculations to return, as a list of names. See the key table for this endpoint; an unrecognised name rejects the whole request. One call costs one credit however many keys you ask for, so request everything you need at once rather than making several calls. amavasyaashtakachandra_dharshandurgashtamiekadashikaalashtamimahalaya_pakshamanvaadhimoondraam_piraipournamipradoshamsankatahara_chathurthiWhich observances to return. Ask for several in one call - the response is keyed by type and the cost is the same. |
| year | integer | required | Year of birth as a number, e.g. 1990. Four digits. Four-digit year. Dates are precomputed for 2006 to 2046; outside that range the response is empty. |
| latitude | number (double) | optional | 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. |
| longitude | number (double) | optional | 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. |
| timezone_as_float | number (double) | optional | 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. |