Changelog

Mudda dasha

Mudda dasha is spelled correctly and lives at /api/astro/mudda-dasha/, next to Muntha in the Tajika & varshaphala section. The old /api/astro/muddha_dasha/ is retired; the new endpoint returns the lords by name and every start as an ISO timestamp rather than planet numbers and a date string with a degree dictionary inside it.

• POST /api/astro/mudda-dasha/

What replaces what

Tajika aspects: use /api/astro/tajika/aspects/ instead of /api/astro/tajaka/. Tajika yogas: /api/astro/tajika/yogas/ instead of /api/astro/tajaka_yoga/. Sahams: /api/astro/sahams/ instead of /api/astro/saham/. Prashnavali: the four /api/astro/prashnavali/ endpoints instead of /api/astro/chakra/. Gun milan: /api/astro/ashtakoota/ with the `compatibility_score` key, which returns the same thirteen values (the eight koota scores, the total out of 36 and the four South Indian checks), instead of /api/astro/gun-milan/. Shadbala: /api/astro/strength/ instead of /api/astro/shadbala/. Nakshatra and rashi dashas: /api/astro/dasha/nakshatra/ and /api/astro/dasha/rashi/ instead of /api/nakshatra_dasha/ and /api/raasi_dasha/. Eclipses: the seven named /api/astro/eclipse/ endpoints instead of the raw /api/astro/eclipse/. KP: /api/astro/kp-chart/ instead of /api/astro/krishnamurti/.

If you call a retired endpoint

A call to any of these with an API key now returns 403 endpoint_not_allowed and uses no credit. Switch to the replacement above; the SDK and the Postman collection already use them.

• POST /api/astro/muddha_dasha/
• POST /api/astro/tajaka/
• POST /api/astro/tajaka_yoga/
• POST /api/astro/saham/
• POST /api/astro/chakra/
• POST /api/astro/gun-milan/
• POST /api/astro/shadbala/
• POST /api/nakshatra_dasha/
• POST /api/raasi_dasha/
• POST /api/astro/eclipse/
• POST /api/astro/krishnamurti/

What changed

The celebrity list and the single-celebrity lookup are no longer offered. A call to either with an API key returns 403 endpoint_not_allowed and uses no credit. Every other endpoint is unchanged. If you stored birth details from these endpoints, you can still send them to the chart endpoints as you would any other birth data.

• GET /api/astro-data/celebrities/
• GET /api/astro-data/celebrities/{id}/

Jamakkol Prashna

Send the local clock time of the question with the place and its UTC offset. You get the eight jama grahas, Udhayam, Arudam and Kavippu, the jamam of the day or night, Kuligan, Emakandam, Mrithyu and Rahu Time, the planets and the panchanga of the moment. Pass arudam_sign when the querent chooses the sign; leave it out to take Arudam from the clock. Checked against jamakkol.com across more than 20 charts; send ayanamsa true_citra with the mean node to match that site exactly.

• POST /api/astro/prashna/jamakkol/

Ashtamangala Prashna

Send the moment and place, the Arudha sign the querent chose, and the cowries as three heaps or the three-digit number. You get the Arudha, the Chatra, the six rasis of Prasna Kriya with the organ each governs, the five Sutras, the planets from both Lagna and Arudha, and the full reading of the number, digit by digit. The sphutas are not repeated here: call /api/astro/prashna/ for the same moment to get them.

• POST /api/astro/prashna/ashtamangala/

What changed

Each of these endpoints shares its request serializer with /api/astro/panchanga/, the one endpoint that genuinely computes all fifty-plus Panchang keys and needs every settable input those keys use between them. The focused endpoints inherited that whole field list regardless — so /day-night-length/, pure sunrise/sunset arithmetic, documented and accepted gulika_rises_at, gulika_portion, mandi_rises_at, mandi_portion, kala_mrityu_rise_at and dhuma_vyatipata_relation (shadow-point settings), samvata_type and mode (era/reckoning switches), and mean_anomaly, eccentricity, eccentric_anomaly, tolerance and nakshatras — thirteen fields, none of which its own calculation ever reads. Each endpoint now documents and accepts only the fields its own calculation actually uses: /samvat/ keeps samvata_type, /lunar-month/ keeps mode, /upagraha/ keeps the six gulika/mandi/kala-mrityu/dhuma-vyatipata fields, and the other 26 keep none of the thirteen.

• POST /api/astro/panchang/
• POST /api/astro/rahu-kaal/
• POST /api/astro/choghadiya/
• POST /api/astro/hora/
• POST /api/astro/auspicious-timings/
• POST /api/astro/inauspicious-timings/
• POST /api/astro/vasa-segments/
• POST /api/astro/lunar-phase/
• POST /api/astro/day-night-length/
• POST /api/astro/sankranti/
• POST /api/astro/tithi/
• POST /api/astro/nakshatra/
• POST /api/astro/nitya-yoga/
• POST /api/astro/karana/
• POST /api/astro/abhijit-muhurat/
• POST /api/astro/brahma-muhurat/
• POST /api/astro/amrit-kaal/
• POST /api/astro/durmuhurat/
• POST /api/astro/disha-shool/
• POST /api/astro/muhurta-table/
• POST /api/astro/sandhya/
• POST /api/astro/panchak/
• POST /api/astro/samvat/
• POST /api/astro/lunar-month/
• POST /api/astro/tarabala/
• POST /api/astro/chandrabala/
• POST /api/astro/lagna/
• POST /api/astro/bhava-cusps/
• POST /api/astro/upagraha/

Why it matters

A field on an endpoint's reference page is a claim that setting it does something. It didn't: sending gulika_rises_at to /day-night-length/ was always silently ignored, which is worse than the field not being there — it invites someone to spend time tuning a setting that can never change the answer. Every endpoint page now lists exactly the knobs that affect that endpoint's own output, nothing more.

Nothing breaks

These fields were never read by these endpoints' calculations, so removing them from the docs and schema changes no endpoint's behavior. If your integration already sends one of them to, say, /day-night-length/, the request still succeeds and the response is unchanged — verified with matched before/after calls across every affected endpoint before this shipped. The only difference is that the reference page and generated SDK types no longer offer a setting that never did anything.

What changed

Fourteen blocks covering Panchang, Rahu Kaal, Choghadiya, Abhijit and Brahma Muhurat, Durmuhurat, Ekadashi/Amavasya/Purnima/Pradosh/Sankashti Chaturthi dates, a Festival Calendar, Rashifal and a Kundli form. Each is a real block editor block, dragged in from the inserter like any core block, with a matching shortcode for anyone still on the Classic Editor.

Why it matters

A site owner who has never written a line of PHP can add a live Panchang widget to their site in the time it takes to drag a block and paste an API key. It is a thin renderer over the same endpoints this changelog covers elsewhere — no calculation logic of its own, so it can never disagree with the API.

The sixteen shodasavarga now all have a route — 8 new

D1 rashi, D4 chaturthamsa, D16 shodasamsa, D20 vimsamsa, D24 chaturvimsamsa, D27 nakshatramsa, D40 khavedamsa and D45 akshavedamsa join the eight already published (D2, D3, D7, D9, D10, D12, D30, D60). NOTHING NEW IS COMPUTED — /api/astro/chart/ could always produce these by passing chart_name, and these routes delegate to the same view, so the numbers are identical by construction. What changes is that they can be found: a route called /navamsa/ is discoverable and a chart_name buried in a request body is not. /api/astro/rashi/ is the same view with the chart pinned and returns byte-identical output to /api/astro/planet-positions/ — a test asserts exactly that, so the two cannot drift.

• POST /api/astro/rashi/
• POST /api/astro/chaturthamsa/
• POST /api/astro/shodasamsa/
• POST /api/astro/vimsamsa/
• POST /api/astro/chaturvimsamsa/
• POST /api/astro/nakshatramsa/
• POST /api/astro/khavedamsa/
• POST /api/astro/akshavedamsa/

Four divisions outside the shodasavarga — 4 new

D5 panchamsa (fame and authority), D6 shashthamsa (health and enemies), D8 ashtamsa (longevity and sudden events) and D11 rudramsa (gains). These are used alongside the classical sixteen rather than being part of them, and each response says so. WORTH KNOWING about D11: two traditions read it in opposite directions — one for gains, as the eleventh house suggests, the other for Rudra and therefore destruction. We do not pick one for you.

• POST /api/astro/panchamsa/
• POST /api/astro/shashthamsa/
• POST /api/astro/ashtamsa/
• POST /api/astro/rudramsa/

Beyond D60 — 3 new

D81 navnavamsa, D108 astottaramsa and D144 dwadasdwadasamsa. THESE ARE COMPOUNDED DIVISIONS and the engine carries two readings of each: a straight division of the rashi into 81, 108 or 144 parts, and a varga of a varga. These routes serve the COMPOUNDED one, because that is what each name literally says — nava-navamsa is the navamsa of the navamsa, dwadas-dwadasamsa the dwadasamsa of the dwadasamsa. The straight-division form is still reachable through /api/astro/chart/ as NavnavamsaChart, AstottaramsaChart and DwadasdwadasamsaChart, and it gives a different sign for most planets — they are different charts, not two spellings of one. A test asserts the two actually differ, so the choice cannot be reversed by accident. At 22, 17 and 12 arcminutes per division these are worth reading only when the birth time is genuinely known to the minute; below that they report the rounding in your birth certificate.

• POST /api/astro/navnavamsa/
• POST /api/astro/astottaramsa/
• POST /api/astro/dwadasdwadasamsa/

The docs now list them in division order

The reference sorted every group alphabetically, which put D10 before D2 and D144 before D16 — a jumble that made the series look incomplete even when it was not, because a reader scanning for D20 had nowhere to look. Divisional charts now sort by division number wherever they are listed.

Nothing existing changed

All fifteen are new routes that pin a chart_name and otherwise delegate to the view already serving /api/astro/planet-positions/. /api/astro/chart/ still accepts every chart_name it did before, including the alternative reckonings that have no route of their own — ParivrittidwayaHora, SomnathDrekkana, JagannathDrekkana and the rest. Those stay where they are: they are variants of a division that already has a route, wanted by someone who knows the name they want.

Rashifal by period and aspect — 6 new

/api/astro/rashifal/ returns a rotating sample of 3–4 aspects, and which ones rotates with the date — so a page for “Aries Health” could not exist, because some days health was not in the sample. These six return EVERY aspect on every call: general, career_business, love_relationships, money_finances, health, education_student, family, travel, and two the base engine never carried, business and professionals. Pass aspect to get just one, which is the shape a per-aspect page wants. Readings are deterministic — the same sign, period, aspect and date always return the same words, so a page can be cached and will not contradict itself on a refresh. Weekly adds the best and challenging days; monthly adds transits, special days and remedies; yearly adds a quarterly forecast and lucky elements. rashi and aspect are case-insensitive, as on the existing endpoint.

• POST /api/astro/rashifal/daily/
• POST /api/astro/rashifal/tomorrow/
• POST /api/astro/rashifal/yesterday/
• POST /api/astro/rashifal/weekly/
• POST /api/astro/rashifal/monthly/
• POST /api/astro/rashifal/yearly/

Nine numerology systems — 10 new

Kabbalah maps a name onto the 22 paths of the Tree, each with its Hebrew letter and tarot trump. Gematria scores Hebrew text under five ciphers (standard, gadol, ordinal, katan, atbash). Tarot gives the birth, partner and name cards; I Ching the birth and name hexagrams on the King Wen 64; Sepharial his own 1920 table with its planetary rulers; Cheiro the Chaldean table read to a compound number. Abjad and isopsephy score Arabic and Greek including the obsolete numeral letters — digamma, koppa, sampi. THREE OF THESE ARE SCRIPT-SPECIFIC: abjad is Arabic, isopsephy Greek, gematria Hebrew, and sent the wrong script they return a value of 0 and list every character in unscored rather than transliterating, because every source transliterates differently and a confident number from an arbitrary choice is worse than an obvious zero.

• POST /api/astro/numerology/kabbalah/
• POST /api/astro/numerology/gematria/
• POST /api/astro/numerology/tarot/
• POST /api/astro/numerology/iching/
• POST /api/astro/numerology/sepharial/
• POST /api/astro/numerology/abjad/
• POST /api/astro/numerology/isopsephy/
• POST /api/astro/numerology/angel/
• POST /api/astro/numerology/aura/
• POST /api/astro/numerology/cheiro/

Lal Kitab houses, planets and chart layout — 3 new

The same fixed-house tradition as the two routes added yesterday, in the three shapes a page actually renders from. /horoscope/ is the chart as twelve sign-slots with each occupant’s degree within its sign. /houses/ gives each house its lord, the grahas whose pakka ghar it is, and who is exalted or debilitated there — pakka_ghar is a LIST, because Mercury and Venus share the 7th, Mars and Saturn the 8th, and Jupiter and Rahu the 12th, and a single value drops one of them. /planets/ gives each graha its dignity and nature. The Moon’s and Mercury’s nature are computed rather than fixed — the Moon from its paksha, Mercury from whether a natural malefic shares its sign — and every row carries nature_basis saying which rule decided it. WORTH KNOWING: position is null for Rahu and Ketu unless they are exalted or debilitated. They rule no sign, so “a friend’s sign” has nothing to measure against.

• POST /api/astro/lal-kitab/horoscope/
• POST /api/astro/lal-kitab/houses/
• POST /api/astro/lal-kitab/planets/

What we still will not answer

Lal Kitab debts (rin) and the Lal Kitab dasha are absent on purpose, and so are the soya and kismat fields other vendors return on their houses endpoint. The eight debt names are agreed across sources; the conditions that raise each one are not — published rules for pitra rin alone disagree in ways that give different answers for the same chart. The same is true of soya. We would rather return nothing than publish a verdict about someone’s ancestors on a coin toss, so those fields are missing and the response says why.

Nothing existing changed

All nineteen are new routes. /api/astro/rashifal/ still takes the same body and returns the same rotating sample; the nine new numerology systems are their own module rather than new values on /api/astro/numerology/, so the existing system and keys fields are untouched. Cheiro reuses the Chaldean letter table and the compound meanings the API already carried instead of restating them.

Finished PDF reports — 2 new

The response body IS the PDF. There is no second request and no hosted file: we store nothing, so there is no link for anyone else to find. Do not call .json() on these — write the bytes to disk (curl -o report.pdf, res.arrayBuffer(), response.content). The horoscope is around 27 pages with a generated contents page; the year book divides the next twelve months by Vimshottari pratyantardasha rather than by calendar month, so its sections begin and end on dates your chart dictates. Both take an optional branding block — company name, contacts, and a logo_url we fetch and draw on the cover — so your customer sees your name and not ours. Both are deterministic: the same birth data gives the same document. Typical time is under two seconds.

• POST /api/astro/pdf/horoscope/ · 25 credits
• POST /api/astro/pdf/yearbook/ · 25 credits

Kala Sarpa and Karakamsa — 2 new

Kala Sarpa returns which grahas fell on which side of the Rahu–Ketu axis, not just a yes or no — most charts are not Kala Sarpa, and the two lists show whether a chart missed by one graha or by four. The named form (Anant, Kulik, Vasuki …) is filled in only when the yoga is actually formed. WORTH KNOWING: /api/astro/karakamsa/ ranks the chara karakas by degree WITHIN the sign and will name a different Atmakaraka from /api/astro/chara-karakas/ for most charts. The two are computed differently and are not interchangeable; prefer the new one for karakamsa work.

• POST /api/astro/kalsarp/
• POST /api/astro/karakamsa/

Sarvatobhadra chakra — 1 new

The nine-by-nine transit board, with the whole grid returned alongside the placements so you can draw it rather than only read a verdict from it — every cell says what it holds, its shading, and the four pada syllables of its nakshatra. Pass transit_date_time to put the transiting grahas on the same board; hits_natal then lists those whose vedha falls on a nakshatra your natal chart occupies. Only positional vedha is applied, and rule says so in every response, because the schools differ and an unlabelled answer cannot be checked. A nakshatra spelling we cannot place is returned under unplaced rather than dropped.

• POST /api/astro/sarvatobhadra/

Lal Kitab — 2 new

A separate North Indian tradition, and the first thing to know is that IN LAL KITAB THE HOUSES ARE FIXED TO THE SIGNS — house 1 is always Aries, through to house 12 always Pisces, for every chart. A planet’s house is its sign number, so these WILL disagree with /api/astro/chart/ and /api/astro/planet-positions/ for almost everyone. That is the system, not an error. Each graha comes back with its pakka ghar and whether it is sitting in it. The varshphal is arithmetic rather than astronomical: every planet advances one house per completed year of age, so the annual chart returns to the natal arrangement every twelfth year.

• POST /api/astro/lal-kitab/chart/
• POST /api/astro/lal-kitab/varshphal/

The playground can hand you the file

Running an endpoint that answers with a file now shows its name, type and size with a Download button, instead of trying to render the bytes as text. The reference page for those endpoints no longer tells you to decompress and parse them either — that wording belonged to the gzipped-JSON routes and was wrong for a PDF.

Nothing existing changed

The five calculation endpoints are new routes that delegate to the views already serving /api/astro/planet-positions/ and the divisional charts, so their numbers are identical by construction. The PDF reports are assembled by calling those same endpoints internally — the positions printed on page 3 are exactly what /api/astro/planet-positions/ returns — and the whole report is billed as one call, not the twenty-five it is built from.

Conditional nakshatra dashas — 7 new

Planet-based: every lord in the response is a graha. All seven are CONDITIONAL — the classical texts apply them only when a chart meets a particular condition, so check /api/astro/dasha_applicability/ before offering one as a reading.

• POST /api/astro/dasha/dwadashottari/
• POST /api/astro/dasha/panchottari/
• POST /api/astro/dasha/sataabdika/
• POST /api/astro/dasha/chaturaseeti-sama/
• POST /api/astro/dasha/dwisaptati/
• POST /api/astro/dasha/shattrimsa-sama/
• POST /api/astro/dasha/budhi-gati/

Jaimini rashi dashas — 15 new

Sign-based: every lord here is a rashi, not a planet. That is the difference to watch — the lord field means a different kind of thing than it does in the nakshatra dashas above, and reading the wrong one gives you output you cannot interpret.

• POST /api/astro/dasha/drig/
• POST /api/astro/dasha/nirayana-shoola/
• POST /api/astro/dasha/shoola/
• POST /api/astro/dasha/sthira/
• POST /api/astro/dasha/trikona/
• POST /api/astro/dasha/brahma/
• POST /api/astro/dasha/chakra/
• POST /api/astro/dasha/kendradhi/
• POST /api/astro/dasha/lagnamsaka/
• POST /api/astro/dasha/mandooka/
• POST /api/astro/dasha/navamsa/
• POST /api/astro/dasha/paryaaya/
• POST /api/astro/dasha/sandhya/
• POST /api/astro/dasha/tara-lagna/
• POST /api/astro/dasha/yogardha/

One branch instead of the whole tree — 1 new

levels caps how DEEP a dasha response goes, but still returns every period at that depth: levels=3 on Vimshottari is every pratyantardasha under every antardasha under every mahadasha — 95 KB measured. Send {"lords": ["moon", "mars"], "levels": 1} and you get only the periods inside that one antardasha, about 1.8 KB. It saves transfer and parsing, not computation.

• POST /api/astro/dasha/drill/

Astrology chat — 1 new

Send birth details and a question, get an answer in prose — with the classical passages it drew on, each cited and scored, so the reasoning can be checked. Birth details come from YOUR request rather than an account, so you can ask on behalf of any of your users. Add compare_with for compatibility questions, and pass up to twenty earlier turns in history. Nothing is stored between calls. Costs 25 credits rather than 1, because each answer runs a language model over the computed chart; a failed or empty answer costs nothing.

• POST /api/astro/chat/ · 25 credits

Thirty dasha systems, now grouped by family

With these, thirty systems have a named endpoint, up from eight — the rest were reachable only by passing a string to /api/nakshatra_dasha/ or /api/raasi_dasha/, so searching for “narayana dasha” found nothing. In the reference they are now split into three groups — nakshatra (planet), rashi (Jaimini), and tools — rather than one alphabetical list of thirty-five that put Brahma dasha next to Budhi Gati dasha.

Nothing existing changed

/api/nakshatra_dasha/ and /api/raasi_dasha/ are untouched, and the eight dasha endpoints that already existed behave exactly as before — each new route delegates to the same parent view, so the numbers are identical by construction rather than by a copy that could drift. The chat endpoint is separate from the app’s existing /api/ai/ routes, which are unchanged.

What is new

POST /api/astro/prashnavali/ram-shalaka/ returns the 225 chaupais of the Ram Shalaka Prashnavali, each with its Devanagari letter, the chaupai, where in the Ramcharitmanas it appears, and an English answer. /api/astro/prashnavali/hanuman/ returns the 49 numbered answers, /api/astro/prashnavali/sai/ the 720 Sai answers, and /api/astro/prashnavali/mavji/ the 64 Mavji Maharaj readings in Hindi and English. All four are grouped under a new Avatar chakra category in the reference.

Three things they do that the parent does not

The filter is optional everywhere. /api/astro/chakra/ rejects a sai_prashnavali request that arrives without a number; these endpoints return the whole set instead, which is how oracle data is normally used — fetch once, cache, index locally. Entries come back as a LIST with the index carried on each entry, rather than an object keyed by a stringified number, so you can iterate in order without sorting string keys numerically (which otherwise runs 1, 10, 100, 11). And every response carries a count, so a single-entry lookup is distinguishable from a full fetch without inspecting the payload.

Nothing existing changed

/api/astro/chakra/ is untouched. It still serves all four datasets behind its keys field, still returns the same {key: data} shape, and still returns 400 for sai_prashnavali without a number. If you are already integrated against it, nothing here affects you — these are additional routes, not a replacement.

Renamed in the reference

"KP (Krishnamurti) chart" and "Krishnamurti paddhati" are now "KP chart (cusps, signs and planets)" and "KP parts (pick with keys)" — the first hands you the whole chart, the second makes you name the parts you want. "House lord placements" and "House lord placement", which differed by one letter, are now "(all 144)" and "(one pair)". Two endpoints both called "Pancha Pakshi" are now "(bird activity by hora)" and "(day in ten yamas)". "Birth panchanga effects" and "Birth panchanga readings" are now "(reference table)" and "(your elements)".

Routes did not change

These are display names in the documentation only. Every route, request field and response field is exactly as it was — nothing to update in your integration. If you have bookmarked a docs page, the URL still works; only the label at the top is clearer.

Screenshots on the reference pages

43 endpoint pages now carry a screenshot of that endpoint's data rendered in a working interface — panchang, choghadiya, the festival calendar, retrogrades, eleven regional calendars, birth charts and more. A field table tells you the shape of a response but not what it is for, and one look usually settles whether it is the endpoint you want. The docs index and the homepage carry the same set.

What changed

/api/astro/chart/ now accepts an optional render field. Leave it out and nothing changes — the response is exactly what it has always been. Set it to "svg" and two more fields appear alongside the usual four: layout (every house or sign cell's polygon points, label position, and which planets occupy it) and svg (rendered markup you can drop straight into a page). chart_style picks North Indian (the diamond, fixed houses, rotating signs) or South Indian (the fixed sign grid, rotating houses); svg_size, theme, label_style, show_degrees and four *_color fields control how it looks.

Why it matters

Building a chart wheel from raw longitudes is real work — house geometry, sign rotation, label placement — that every integrator was repeating from scratch. Now it is one field on a call you were already making. The layout geometry is there for anyone rendering natively in React, Canvas, Flutter or SwiftUI rather than using our markup.

Nothing existing changed

render defaults to "none" and every other new field defaults to a value that does nothing. A request that does not mention any of them gets back a response verified byte-for-byte identical to before this shipped, across every chart type and option this endpoint accepts.

Dashas you can search for

We already computed thirty dasha systems — eleven nakshatra dashas and nineteen rashi dashas, each to several levels of nesting — but they were values of a dasha_type string on two endpoints called nakshatra_dasha and raasi_dasha. Searching for “vimshottari dasha” found nothing. There are now named routes: /api/astro/dasha/vimshottari/, /yogini/, /ashtottari/, /chara/, /narayana/, /kalachakra/ and more, plus /api/astro/dasha/systems/ listing every system with the endpoint that serves it. The two original endpoints are untouched and keep working.

Which dasha is running right now

/api/astro/dasha/current/ answers the question the timeline endpoints could not: it returns the chain from mahadasha down — “Jupiter / Ketu / Mercury” — with each level’s start and end, how far through it you are, and how many days remain. Previously that meant fetching the whole tree, recursing it and comparing dates in your own code.

Traditional and Hellenistic Western astrology

/api/astro/traditional/dignities/ returns domicile, exaltation, triplicity, term and face for every planet with Lilly’s score; /almuten/ gives the planet with most dignity over each chart point; /sect/ says whether a chart is diurnal or nocturnal and what follows from it; /profections/ gives the annual, monthly and daily profection with the Lord of the Year. These are tropical, as the doctrine requires, and the response says which bound and triplicity tables were used — sources disagree, and a score computed against a different table is a different number.

Derived charts and the Moon

Draconic, harmonic, antiscia, heliocentric and Davison charts under /api/astro/western/, plus /api/astro/lunar/void-of-course/ and /api/astro/lunar/mansions/. Void of course is a forward search rather than a snapshot: it scans to the Moon’s sign change, reports every aspect that will perfect and exactly when, and tells you when the void begins and ends.

Chinese Four Pillars

/api/astro/chinese/four-pillars/, /bazi/, /zodiac/ and /luck-pillars/. The Chinese year begins at Lichun, around 4 February — not on 1 January and not at Chinese New Year, which is a lunar date and governs the festival rather than the chart. A birth on 20 January 2024 returns a Water Rabbit, not a Wood Dragon. Both the day-boundary and true-solar-time conventions are request fields, because practitioners differ and each changes the chart.

Tarot

/api/astro/tarot/draw/, /spread/, /yes-no/ and /deck/. Every draw returns the seed that produced it, and sending that seed back reproduces the draw exactly — same cards, same order, same orientation. That is what lets you store a reading and show it again instead of handing the querent a different answer to the same question. Six named spreads up to the ten-card Celtic Cross, each position labelled.

Also new

/api/astro/eclipse/visibility-path/ traces where a solar eclipse is total as coordinates you can draw on a map, with the point of greatest eclipse and its Saros series. Nine further endpoints carve out calculations that previously required knowing which keys to ask a larger endpoint for: ashtakavarga prastara and sodhana, Tajika aspects and yogas, planet horizon and equatorial coordinates, moon illumination, vasa segments and cazimi.

Nothing existing changed

Every endpoint added here is a new route. No request body, response shape or field name on any existing endpoint was altered, and no endpoint was removed or renamed. Pricing is unchanged: one successful call costs one credit, whatever it returns.

What changed

Endpoints like /api/astro/sunrise/, /api/astro/tithi/, /api/astro/navamsa/ and /api/astro/rahu-kaal/ each take the usual birth or date fields and return only the thing they are named after. The existing combined endpoints are unchanged and keep working exactly as before.

Why it matters

Showing a sunrise time no longer means requesting, paying for and parsing a full panchang response. Smaller payloads, less mapping code, and a request body you can read.

How to start

Browse the reference and send the sample request with your key in the X-API-Key header. Pricing is unchanged: one successful call costs one credit, whatever it returns.

What changed

Search matches the feature, not just the endpoint name. Typing “manglik” finds the dosha endpoint even though the word “manglik” is not in its name, and the result tells you which field matched.

Why it matters

Several hundred individual fields sit behind the endpoint list. Without search on the field names, finding the one you need meant opening endpoints one at a time and reading their responses.

What changed

The occult-api MCP server exposes endpoint search, endpoint descriptions and calls as tools. Point it at your API key and an assistant can find the right endpoint and call it directly.

Why it matters

It is the fastest way to try the API against a real question before you commit to building anything, and it doubles as a working reference implementation of the request format.

What changed

Each endpoint page links straight into the playground with its sample request already filled in. Change the latitude, the date or the ayanamsa and send it again.

Why it matters

Reading a sample response tells you the shape of the data. Sending your own inputs tells you whether it answers your question.

What changed

Sign up, generate a key, and send it in the X-API-Key header. Credits are deducted per successful call — a failed request is never charged.

Why it matters

No per-endpoint price list to reason about. Calculations run against NASA JPL ephemeris data with a full set of classical and modern ayanamsas.