A fair question from any engineer: the Swiss Ephemeris is free and accurate, so why pay for a panchang API? Because positions are the easy part. This is the list of what sits between "Moon longitude at 05:00 UT" and "today is Shukla Saptami, Rahu Kaal 11:11–12:30, Diwali is on the 29th", with what each layer takes to get right.
Layer 0: positions (the ephemeris does this)
Geocentric apparent longitudes of the Sun, Moon and planets. Both the Swiss Ephemeris and our API agree with NASA JPL Horizons to about 0.05 arc-seconds (published benchmark). If this is all you need, use the library.
Layer 1: sunrise, for a place, with the right definition
Hindu civil days start at local sunrise, so every panchang value depends on it. You need the observer's latitude, longitude, refraction, the upper limb of the disc, and a search that does not break at high latitudes or on the day the Moon does not rise. Our sunrise and moonrise agree with JPL's limb crossing within 9 seconds across six cities; it took a dedicated test set to get there.
Layer 2: tithi, nakshatra, yoga and karana as time segments
A tithi is each 12° of Moon–Sun elongation. Turning that into "Saptami ends at 14:13:59" means root-finding on the elongation curve, handling the 360° wrap, and deciding which segment the day is labelled with (the one current at sunrise). Karanas are half-tithis, yogas use the sum of longitudes, nakshatras divide the sidereal zodiac into 27 and need an ayanamsa. Four root-finders, each with edge cases.
Layer 3: kshaya and vriddhi
Some tithis skip a sunrise (kshaya) and some span two (vriddhi). The calendar still has to assign every date one tithi and observe the skipped one somewhere. The rules differ for Ekadashi and Janmashtami. This is where most home-built calendars first disagree with the printed panchang.
Layer 4: festival observance moments
Festivals are not "the date with that tithi". Diwali is the day Amavasya covers pradosh kaal; Rama Navami needs Navami at midday; Sankashti needs Chaturthi at moonrise; Raksha Bandhan must avoid Bhadra. Our engine encodes udaya, pradosh, nishita, moonrise, aparahna, madhyahna and arunodaya moments per festival and is checked against 4,427 printed-calendar entries in 14 cities. Writing these rules is months of work; verifying them needs the calendars.
Layer 5: months, adhik maas and naming
Amanta or purnimanta month names (same festival, different month label by region), adhik maas detection from solar ingress, Vikram and Shaka years, Sankranti-based solar months for Tamil and Malayalam calendars.
Layer 6: timezones and the diaspora
The same sky gives different civil dates in Delhi, London and Toronto. You need IANA timezone handling with daylight saving on the date in question, and every rule above has to run in the user's local day. (See why festival dates differ by city.)
Layer 7: names, languages and keeping it running
Tithi, nakshatra and festival names in Hindi, Tamil, Bengali and more; narratives if you show readings; ephemeris files on your servers; tests that catch a regression before a festival app ships the wrong day.
The honest comparison
| You need | Swiss Ephemeris yourself | Panchang API |
|---|---|---|
| Planet positions only | Best choice | Works, but unnecessary |
| Daily panchang for one fixed city | 2–4 weeks for layers 1–3 | One call |
| Festival calendar for any city | Months, plus printed calendars to verify | One call, verified |
| Full control, offline, no vendor | Yes | No |
| Cost at 10k calls a month | Your engineering time | About ₹999 / $29 |
If you are building an astrology engine as your product, build it. If the panchang is a feature in a bigger app, the API is cheaper than the first week of layer 3. The calls below return layers 1–6 for Delhi on one day; try them with a free key.
curl "https://api.lifeastroapi.com/v1/panchang/advanced?date=2027-01-15&tz=Asia/Kolkata&lat=28.6139&lon=77.209" -H "Authorization: Bearer YOUR_API_KEY"
curl "https://api.lifeastroapi.com/v1/festivals/month?year=2027&month=10&tz=Asia/Kolkata&lat=28.6139&lon=77.209" -H "Authorization: Bearer YOUR_API_KEY"