How to build a Vedic astrology app

Architecture, the endpoints behind each screen, credit costs, caching, languages and going to production.

A Vedic astrology app usually has five areas: a daily panchang, the user's kundli, horoscopes, kundli matching, and a festival calendar. This guide maps each to the LifeAstroAPI endpoints that power it and covers the decisions that matter before launch.

1. Architecture: keep the API key on a server

Never put your API key in a mobile app or browser bundle; anyone can extract it. Call LifeAstroAPI from your own backend (a small Node, Python or serverless function is enough) and have the app talk to that. The backend is also where you cache results and check your own user's plan.

2. The endpoints behind each screen

Screen	Endpoint	Credits
Today's panchang with Rahu Kaal and Choghadiya	`/v1/panchang/advanced`	30
Lighter panchang (elements, rise/set, end times)	`/v1/panchang/basic`	20
Monthly calendar page	`/v1/panchang/monthly?include=sheet`	30
Festivals of a month	`/v1/festivals/month`	20
Ekadashi / Pradosh / Purnima list for a year	`/v1/festivals/vrat`	30
Birth chart planets and lagna	`/v1/chart/planets`, `/v1/chart/ascendant`	10 + 10
Navamsa and other vargas	`/v1/chart/divisional/D9`	20
Current dasha	`/v1/dasha/vimshottari/current`	10
Full dasha tree	`/v1/dasha/vimshottari`	20
Daily rashifal	`/v1/horoscope/daily`	10
Kundli matching (36 gunas)	`/v1/milan/ashtakoota`	30
Mangal Dosha	`/v1/milan/mangal-dosha`	10
Wedding / griha pravesh dates	`/v1/muhurta/best-time`	30
Birth-place search	`/v1/geo/search`	free

Every endpoint's current cost is in the API reference. The free tier (1,500 credits a month) is enough to build and test all of the above.

3. Inputs: date, time, timezone and place

Almost every endpoint takes date (YYYY-MM-DD), time (HH:MM, 24-hour), tz (an IANA name such as Asia/Kolkata, or a fixed offset) and lat/lon. Use IANA names: they get daylight saving right for users in London, Toronto or Sydney. The birth-place picker can use /v1/geo/search?q=..., which returns latitude, longitude and timezone for each match.

4. Cache what never changes

A birth chart, dasha tree or matching result is fixed for the same birth data: store it once per user.
A panchang is fixed per city and date: cache it per (city, date) and every user in that city shares it.
Festival lists are fixed per city and year: fetch once a year per city.

With these three rules most apps spend credits only on new users and new cities.

5. Hindi and regional languages

Pass locale=hi (or another supported locale) for localised names and narratives where an endpoint supports it. Festival names come back with both name_en and name_hi.

6. Festival dates that are right for every city

Festival and vrat dates depend on local sunrise, moonrise and evening twilight, so the same festival can fall on different days in Delhi and Toronto. Always pass the user's own location. Our festival engine is verified against printed panchangs of 14 cities.

GET https://api.lifeastroapi.com/v1/festivals/vrat?year=2027&type=ekadashi&lat=28.6139&lon=77.209&tz=Asia/Kolkata

{
  "date": "2027-01-03",
  "name_en": "Saphala Ekadashi",
  "name_hi": "सफला एकादशी",
  "paksha": "Krishna",
  "windows": [
    { "label": "tithi",  "start": "14:25", "end": "16:09" },
    { "label": "parana", "start": "07:14", "end": "10:42" }
  ],
  "note": "smarta and vaishnava on the same day"
}

7. Going to production

Rate limits are per plan (13 requests a minute on Free, 250 on Pro). Queue bursty jobs.
On HTTP 429, wait for the Retry-After header. The official Node SDK does this for you.
Errors come back as {"error": {"code", "message", "request_id"}}; log the request id.
Test with sample data, never a real customer's birth details.