Changelog

Mudda Dasha

Mudda Dasha ist jetzt richtig geschrieben und liegt unter /api/astro/mudda-dasha/, neben Muntha im Bereich Tajika & Varshaphala. Das alte /api/astro/muddha_dasha/ ist abgeschaltet. Der neue Endpoint liefert die Herrscher mit Namen und jeden Beginn als ISO-Zeitstempel – statt Planetennummern und eines Datums-Strings, in dem ein Grad-Dictionary steckt.

• POST /api/astro/mudda-dasha/

Was wodurch ersetzt wird

Tajika-Aspekte: /api/astro/tajika/aspects/ statt /api/astro/tajaka/. Tajika-Yogas: /api/astro/tajika/yogas/ statt /api/astro/tajaka_yoga/. Sahams: /api/astro/sahams/ statt /api/astro/saham/. Prashnavali: die vier Endpoints unter /api/astro/prashnavali/ statt /api/astro/chakra/. Gun Milan: /api/astro/ashtakoota/ mit dem Key `compatibility_score`, der dieselben dreizehn Werte liefert (die acht Koota-Punkte, die Gesamtpunktzahl von maximal 36 und die vier südindischen Prüfungen), statt /api/astro/gun-milan/. Shadbala: /api/astro/strength/ statt /api/astro/shadbala/. Nakshatra- und Rashi-Dashas: /api/astro/dasha/nakshatra/ und /api/astro/dasha/rashi/ statt /api/nakshatra_dasha/ und /api/raasi_dasha/. Finsternisse: die sieben benannten Endpoints unter /api/astro/eclipse/ statt des rohen /api/astro/eclipse/. KP: /api/astro/kp-chart/ statt /api/astro/krishnamurti/.

Wenn du einen abgeschalteten Endpoint aufrufst

Ein Aufruf eines dieser Endpoints mit API-Schlüssel liefert jetzt 403 endpoint_not_allowed und verbraucht keinen Credit. Steig auf den oben genannten Nachfolger um; das SDK und die Postman-Collection nutzen ihn bereits.

• 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/

Was sich geändert hat

Die Liste der Prominenten und die Abfrage einzelner Prominenter gibt es nicht mehr. Ein Aufruf eines der beiden Endpoints mit API-Schlüssel liefert 403 endpoint_not_allowed und verbraucht keinen Credit. Alle anderen Endpoints bleiben unverändert. Hast du Geburtsdaten aus diesen Endpoints gespeichert, kannst du sie weiterhin wie alle anderen Geburtsdaten an die Horoskop-Endpoints schicken.

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

Jamakkol Prashna

Schick die lokale Uhrzeit der Frage zusammen mit dem Ort und dessen UTC-Offset. Du bekommst die acht Jama-Grahas, Udhayam, Arudam und Kavippu, das Jamam des Tages oder der Nacht, Kuligan, Emakandam, Mrithyu und Rahu Time, die Planeten und das Panchanga des Moments. Übergib arudam_sign, wenn der Fragende das Zeichen selbst wählt; lässt du es weg, wird Arudam aus der Uhrzeit bestimmt. An mehr als 20 Horoskopen mit jamakkol.com abgeglichen. Für exakt dieselben Werte wie dort schick ayanamsa true_citra mit dem mittleren Mondknoten.

• POST /api/astro/prashna/jamakkol/

Ashtamangala Prashna

Schick Zeitpunkt und Ort, das vom Fragenden gewählte Arudha-Zeichen und die Kaurischnecken als drei Häufchen oder als dreistellige Zahl. Du bekommst das Arudha, das Chatra, die sechs Rasis der Prasna Kriya samt dem Organ, das jede regiert, die fünf Sutras, die Planeten von Lagna und von Arudha aus gezählt sowie die vollständige Deutung der Zahl, Ziffer für Ziffer. Die Sphutas sind hier nicht noch einmal enthalten: Ruf dafür /api/astro/prashna/ für denselben Zeitpunkt auf.

• POST /api/astro/prashna/ashtamangala/

Was sich geändert hat

Alle diese Endpoints teilen ihren Anfrage-Serializer mit /api/astro/panchanga/ – dem einen Endpoint, der wirklich alle über fünfzig Panchang-Keys berechnet und jede einstellbare Eingabe braucht, die diese Keys zusammen verwenden. Die spezialisierten Endpoints haben diese komplette Feldliste trotzdem geerbt. So hat /day-night-length/, reine Rechnerei mit Sonnenauf- und -untergang, folgende Felder dokumentiert und akzeptiert: gulika_rises_at, gulika_portion, mandi_rises_at, mandi_portion, kala_mrityu_rise_at und dhuma_vyatipata_relation (Einstellungen für Schattenpunkte), samvata_type und mode (Schalter für Ära und Zählweise) sowie mean_anomaly, eccentricity, eccentric_anomaly, tolerance und nakshatras – dreizehn Felder, von denen seine eigene Berechnung kein einziges liest. Jetzt dokumentiert und akzeptiert jeder Endpoint nur noch die Felder, die seine Berechnung tatsächlich nutzt: /samvat/ behält samvata_type, /lunar-month/ behält mode, /upagraha/ behält die sechs Felder zu gulika/mandi/kala-mrityu/dhuma-vyatipata, und die übrigen 26 behalten keines der dreizehn.

• 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/

Warum das wichtig ist

Ein Feld auf der Referenzseite eines Endpoints verspricht, dass es etwas bewirkt. Das war hier nicht so: gulika_rises_at an /day-night-length/ zu schicken, wurde schon immer stillschweigend ignoriert. Das ist schlimmer, als wenn es das Feld gar nicht gäbe – es lädt dazu ein, Zeit in eine Einstellung zu stecken, die das Ergebnis nie ändern kann. Jede Endpoint-Seite listet jetzt genau die Stellschrauben auf, die die Ausgabe dieses Endpoints beeinflussen, und keine weiteren.

Nichts geht kaputt

Die Berechnungen dieser Endpoints haben diese Felder nie gelesen. Sie aus Doku und Schema zu entfernen, ändert also an keinem Endpoint das Verhalten. Schickt deine Integration eines davon bereits mit, etwa an /day-night-length/, ist die Anfrage weiterhin erfolgreich und die Antwort unverändert – vor der Veröffentlichung an jedem betroffenen Endpoint mit Vorher-nachher-Aufrufen geprüft. Der einzige Unterschied: Die Referenzseite und die generierten SDK-Typen bieten keine Einstellung mehr an, die ohnehin nie etwas bewirkt hat.

Was sich geändert hat

Vierzehn Blöcke für Panchang, Rahu Kaal, Choghadiya, Abhijit und Brahma Muhurat, Durmuhurat, Termine für Ekadashi/Amavasya/Purnima/Pradosh/Sankashti Chaturthi, einen Festkalender, Rashifal und ein Kundli-Formular. Jeder ist ein echter Block für den Block-Editor, den du wie jeden Standardblock aus dem Inserter ziehst – mit passendem Shortcode für alle, die noch den klassischen Editor nutzen.

Warum das wichtig ist

Wer eine Website betreibt und noch nie eine Zeile PHP geschrieben hat, baut ein Live-Panchang-Widget ein – in der Zeit, die es dauert, einen Block hineinzuziehen und einen API-Schlüssel einzufügen. Das Plugin ist nur eine dünne Darstellungsschicht über denselben Endpoints, um die es an anderer Stelle in diesem Changelog geht. Es hat keine eigene Rechenlogik und kann der API daher nie widersprechen.

Alle sechzehn Shodasavarga haben jetzt eine Route – 8 neu

D1 Rashi, D4 Chaturthamsa, D16 Shodasamsa, D20 Vimsamsa, D24 Chaturvimsamsa, D27 Nakshatramsa, D40 Khavedamsa und D45 Akshavedamsa kommen zu den acht bereits veröffentlichten hinzu (D2, D3, D7, D9, D10, D12, D30, D60). ES WIRD NICHTS NEU BERECHNET: /api/astro/chart/ konnte diese Horoskope schon immer über chart_name liefern, und die neuen Routen delegieren an dieselbe View – die Zahlen sind also zwangsläufig identisch. Neu ist, dass man sie findet: Eine Route namens /navamsa/ ist auffindbar, ein chart_name tief im Anfrage-Body nicht. /api/astro/rashi/ ist dieselbe View mit festgelegtem Horoskop und liefert bytegenau dieselbe Ausgabe wie /api/astro/planet-positions/. Ein Test prüft genau das, damit die beiden nicht auseinanderlaufen können.

• 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/

Vier Teilungen außerhalb der Shodasavarga – 4 neu

D5 Panchamsa (Ruhm und Autorität), D6 Shashthamsa (Gesundheit und Feinde), D8 Ashtamsa (Langlebigkeit und plötzliche Ereignisse) und D11 Rudramsa (Gewinne). Sie werden zusätzlich zu den klassischen sechzehn genutzt, gehören aber nicht dazu – und jede Antwort sagt das auch. GUT ZU WISSEN zu D11: Zwei Traditionen deuten es gegensätzlich – die eine auf Gewinne, wie es das elfte Haus nahelegt, die andere auf Rudra und damit auf Zerstörung. Wir treffen diese Wahl nicht für dich.

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

Jenseits von D60 – 3 neu

D81 Navnavamsa, D108 Astottaramsa und D144 Dwadasdwadasamsa. DAS SIND ZUSAMMENGESETZTE TEILUNGEN, und die Engine kennt jeweils zwei Lesarten: eine direkte Teilung des Rashi in 81, 108 oder 144 Abschnitte und ein Varga eines Varga. Diese Routen liefern die ZUSAMMENGESETZTE Variante, denn genau das sagt jeder Name wörtlich: Nava-Navamsa ist das Navamsa des Navamsa, Dwadas-Dwadasamsa das Dwadasamsa des Dwadasamsa. Die direkte Teilung bleibt über /api/astro/chart/ als NavnavamsaChart, AstottaramsaChart und DwadasdwadasamsaChart erreichbar und ergibt für die meisten Planeten ein anderes Zeichen – es sind verschiedene Horoskope, nicht zwei Schreibweisen desselben. Ein Test stellt sicher, dass sich die beiden wirklich unterscheiden, damit diese Entscheidung nicht versehentlich umgedreht wird. Bei 22, 17 und 12 Bogenminuten pro Abschnitt lohnt sich die Deutung nur, wenn die Geburtszeit wirklich auf die Minute genau bekannt ist. Andernfalls spiegeln sie nur die Rundung in deiner Geburtsurkunde wider.

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

Die Doku sortiert sie jetzt nach Teilung

Die Referenz hat jede Gruppe alphabetisch sortiert. Dadurch stand D10 vor D2 und D144 vor D16 – ein Durcheinander, durch das die Reihe unvollständig wirkte, auch wenn sie es nicht war: Wer nach D20 suchte, wusste nicht, wo er schauen sollte. Teilhoroskope werden jetzt überall nach ihrer Teilungszahl sortiert.

Bestehendes bleibt unverändert

Alle fünfzehn sind neue Routen, die einen chart_name festlegen und ansonsten an die View delegieren, die schon /api/astro/planet-positions/ bedient. /api/astro/chart/ akzeptiert weiterhin jeden chart_name wie bisher, auch die alternativen Berechnungsweisen ohne eigene Route – ParivrittidwayaHora, SomnathDrekkana, JagannathDrekkana und die übrigen. Die bleiben, wo sie sind: Es sind Varianten einer Teilung, die bereits eine Route hat, und wer sie braucht, kennt ihren Namen.

Rashifal nach Zeitraum und Lebensbereich – 6 neu

/api/astro/rashifal/ liefert eine wechselnde Auswahl von 3–4 Lebensbereichen, und welche das sind, hängt vom Datum ab. Eine Seite für „Widder: Gesundheit“ war damit unmöglich, weil Gesundheit an manchen Tagen gar nicht dabei war. Die sechs neuen Endpoints liefern bei jedem Aufruf ALLE Bereiche: general, career_business, love_relationships, money_finances, health, education_student, family, travel und zwei, die die Basis-Engine nie hatte, business und professionals. Mit aspect bekommst du nur einen davon – genau das, was eine Seite pro Lebensbereich braucht. Die Deutungen sind deterministisch: Gleiches Zeichen, gleicher Zeitraum, gleicher Bereich und gleiches Datum ergeben immer denselben Text. Eine Seite lässt sich also cachen und widerspricht sich beim Neuladen nicht. Die Wochenversion nennt zusätzlich die besten und die schwierigen Tage, die Monatsversion Transite, besondere Tage und Abhilfen, die Jahresversion eine Prognose pro Quartal und Glückselemente. Bei rashi und aspect spielt Groß- und Kleinschreibung keine Rolle, wie beim bestehenden 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/

Neun Numerologie-Systeme – 10 neu

Kabbala bildet einen Namen auf die 22 Pfade des Lebensbaums ab, jeden mit seinem hebräischen Buchstaben und seiner Trumpfkarte im Tarot. Gematria bewertet hebräischen Text nach fünf Chiffren (standard, gadol, ordinal, katan, atbash). Tarot liefert Geburts-, Partner- und Namenskarte, I Ging die Geburts- und Namenshexagramme aus den 64 nach King Wen, Sepharial seine eigene Tabelle von 1920 mit ihren planetaren Herrschern, Cheiro die chaldäische Tabelle bis zur zusammengesetzten Zahl. Abjad und Isopsephie bewerten Arabisch und Griechisch einschließlich der veralteten Zahlbuchstaben Digamma, Koppa und Sampi. DREI DAVON SIND AN EINE SCHRIFT GEBUNDEN: Abjad an Arabisch, Isopsephie an Griechisch, Gematria an Hebräisch. Bekommen sie die falsche Schrift, liefern sie den Wert 0 und listen jedes Zeichen unter unscored auf, statt zu transliterieren. Denn jede Quelle transliteriert anders, und eine selbstsichere Zahl aus einer willkürlichen Wahl ist schlimmer als eine offensichtliche Null.

• 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: Häuser, Planeten und Horoskop-Layout – 3 neu

Dieselbe Tradition fester Häuser wie bei den beiden gestern hinzugekommenen Routen, in den drei Formen, aus denen eine Seite tatsächlich rendert. /horoscope/ ist das Horoskop als zwölf Zeichenfelder, jeweils mit dem Grad des Bewohners innerhalb seines Zeichens. /houses/ nennt für jedes Haus den Herrscher, die Grahas, deren Pakka Ghar es ist, und wer dort erhöht oder im Fall steht. pakka_ghar ist eine LISTE, denn Merkur und Venus teilen sich das 7. Haus, Mars und Saturn das 8. und Jupiter und Rahu das 12. – ein Einzelwert würde jeweils einen unterschlagen. /planets/ nennt für jeden Graha Würde und Natur. Die Natur von Mond und Merkur wird berechnet, nicht festgelegt: beim Mond aus seinem Paksha, bei Merkur danach, ob ein natürlicher Übeltäter sein Zeichen teilt. Jede Zeile enthält nature_basis mit der Regel, die den Ausschlag gab. GUT ZU WISSEN: position ist für Rahu und Ketu null, außer sie sind erhöht oder im Fall. Sie herrschen über kein Zeichen, für „das Zeichen eines Freundes“ gibt es also keinen Bezugspunkt.

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

Was wir weiterhin nicht beantworten

Lal-Kitab-Schulden (Rin) und die Lal-Kitab-Dasha fehlen mit Absicht, ebenso die Felder soya und kismat, die andere Anbieter bei ihrem Häuser-Endpoint liefern. Die Namen der acht Schulden sind in allen Quellen gleich, die Bedingungen, die jede einzelne auslösen, aber nicht – schon die veröffentlichten Regeln für Pitra Rin widersprechen sich so, dass sie für dasselbe Horoskop zu unterschiedlichen Antworten führen. Für Soya gilt dasselbe. Lieber geben wir nichts zurück, als ein Urteil über die Vorfahren eines Menschen auf Basis eines Münzwurfs zu veröffentlichen. Deshalb fehlen diese Felder, und die Antwort erklärt, warum.

Bestehendes bleibt unverändert

Alle neunzehn sind neue Routen. /api/astro/rashifal/ erwartet weiterhin denselben Body und liefert dieselbe wechselnde Auswahl. Die neun neuen Numerologie-Systeme bilden ein eigenes Modul, statt neue Werte bei /api/astro/numerology/ einzuführen – die bestehenden Felder system und keys bleiben also unberührt. Cheiro nutzt die chaldäische Buchstabentabelle und die Bedeutungen der zusammengesetzten Zahlen, die es in der API schon gab, statt sie neu zu definieren.

Fertige PDF-Berichte – 2 neu

Der Antwort-Body IST das PDF. Es gibt keine zweite Anfrage und keine gehostete Datei: Wir speichern nichts, also gibt es auch keinen Link, den jemand anderes finden könnte. Ruf hier kein .json() auf, sondern schreib die Bytes auf die Festplatte (curl -o report.pdf, res.arrayBuffer(), response.content). Das Horoskop umfasst rund 27 Seiten mit automatisch erzeugtem Inhaltsverzeichnis. Das Jahrbuch gliedert die nächsten zwölf Monate nach Vimshottari-Pratyantardashas statt nach Kalendermonaten, sodass seine Abschnitte an Daten beginnen und enden, die dein Horoskop vorgibt. Beide nehmen einen optionalen branding-Block an – Firmenname, Kontaktdaten und eine logo_url, deren Logo wir abrufen und aufs Deckblatt setzen –, damit deine Kunden deinen Namen sehen und nicht unseren. Beide sind deterministisch: Dieselben Geburtsdaten ergeben dasselbe Dokument. In der Regel dauert es unter zwei Sekunden.

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

Kala Sarpa und Karakamsa – 2 neu

Kala Sarpa liefert nicht nur Ja oder Nein, sondern welche Grahas auf welcher Seite der Rahu-Ketu-Achse stehen. Die meisten Horoskope haben kein Kala Sarpa, und an den beiden Listen siehst du, ob es um einen Graha oder um vier verfehlt wurde. Die benannte Form (Anant, Kulik, Vasuki …) ist nur ausgefüllt, wenn das Yoga tatsächlich zustande kommt. GUT ZU WISSEN: /api/astro/karakamsa/ ordnet die Chara Karakas nach ihrem Grad INNERHALB des Zeichens und nennt deshalb für die meisten Horoskope einen anderen Atmakaraka als /api/astro/chara-karakas/. Beide werden unterschiedlich berechnet und sind nicht austauschbar; für die Arbeit mit Karakamsa nimm den neuen.

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

Sarvatobhadra-Chakra – 1 neu

Das Transit-Raster mit neun mal neun Feldern. Zusammen mit den Platzierungen kommt das komplette Raster zurück, sodass du es zeichnen kannst, statt nur ein Urteil daraus abzulesen: Jede Zelle nennt ihren Inhalt, ihre Schattierung und die vier Pada-Silben ihres Nakshatra. Übergib transit_date_time, um die laufenden Grahas auf dasselbe Raster zu setzen; hits_natal listet dann die auf, deren Vedha auf ein Nakshatra fällt, das in deinem Geburtshoroskop besetzt ist. Angewendet wird nur die positionelle Vedha, und rule sagt das in jeder Antwort – denn die Schulen unterscheiden sich, und eine Antwort ohne Kennzeichnung lässt sich nicht prüfen. Eine Nakshatra-Schreibweise, die wir nicht zuordnen können, kommt unter unplaced zurück, statt stillschweigend wegzufallen.

• POST /api/astro/sarvatobhadra/

Lal Kitab – 2 neu

Eine eigenständige nordindische Tradition, und das Wichtigste vorweg: IM LAL KITAB SIND DIE HÄUSER FEST AN DIE ZEICHEN GEBUNDEN. Haus 1 ist immer Widder und so weiter bis Haus 12, immer Fische – in jedem Horoskop. Das Haus eines Planeten ist die Nummer seines Zeichens, deshalb WERDEN diese Endpoints für fast alle Menschen von /api/astro/chart/ und /api/astro/planet-positions/ abweichen. Das ist das System, kein Fehler. Jeder Graha kommt mit seinem Pakka Ghar zurück und der Angabe, ob er darin steht. Das Varshphal ist arithmetisch, nicht astronomisch: Jeder Planet rückt pro vollendetem Lebensjahr ein Haus weiter, sodass das Jahreshoroskop alle zwölf Jahre zur Anordnung der Geburt zurückkehrt.

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

Der Playground gibt dir die Datei

Antwortet ein Endpoint mit einer Datei, zeigt der Playground jetzt Name, Typ und Größe mit einem Download-Button an, statt die Bytes als Text darstellen zu wollen. Auch die Referenzseite dieser Endpoints sagt dir nicht mehr, du sollst die Antwort entpacken und parsen – dieser Hinweis gehörte zu den Routen mit gzip-komprimiertem JSON und war für ein PDF falsch.

Bestehendes bleibt unverändert

Die fünf Berechnungs-Endpoints sind neue Routen, die an die Views delegieren, die schon /api/astro/planet-positions/ und die Teilhoroskope bedienen – ihre Zahlen sind also zwangsläufig identisch. Die PDF-Berichte entstehen, indem intern genau diese Endpoints aufgerufen werden: Die Positionen auf Seite 3 sind exakt das, was /api/astro/planet-positions/ liefert. Abgerechnet wird der ganze Bericht als ein Aufruf, nicht als die fünfundzwanzig, aus denen er besteht.

Bedingte Nakshatra-Dashas – 7 neu

Planetenbasiert: Jeder Herrscher in der Antwort ist ein Graha. Alle sieben sind BEDINGT – die klassischen Texte wenden sie nur an, wenn ein Horoskop eine bestimmte Bedingung erfüllt. Prüf also mit /api/astro/dasha_applicability/, bevor du eines davon als Deutung anbietest.

• 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 neu

Zeichenbasiert: Jeder Herrscher ist hier ein Rashi, kein Planet. Genau darauf musst du achten – das Feld lord bezeichnet hier etwas anderes als bei den Nakshatra-Dashas oben, und wer es falsch liest, bekommt eine Ausgabe, mit der sich nichts anfangen lässt.

• 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/

Ein Zweig statt des ganzen Baums – 1 neu

levels begrenzt, wie TIEF eine Dasha-Antwort reicht, liefert aber weiterhin jede Periode auf dieser Ebene: levels=3 bei Vimshottari ergibt jede Pratyantardasha unter jeder Antardasha unter jeder Mahadasha – gemessen 95 KB. Schick {"lords": ["moon", "mars"], "levels": 1}, und du bekommst nur die Perioden innerhalb dieser einen Antardasha, etwa 1,8 KB. Das spart Übertragung und Parsing, aber keine Rechenzeit.

• POST /api/astro/dasha/drill/

Astrologie-Chat – 1 neu

Schick Geburtsdaten und eine Frage und bekomm eine Antwort als Fließtext – samt den klassischen Textstellen, auf die sie sich stützt, jede zitiert und gewichtet, damit sich die Begründung nachprüfen lässt. Die Geburtsdaten kommen aus DEINER Anfrage, nicht aus einem Konto, du kannst also für jeden deiner Nutzer fragen. Für Fragen zur Partnerschaft ergänzt du compare_with, und in history kannst du bis zu zwanzig frühere Gesprächsrunden mitgeben. Zwischen den Aufrufen wird nichts gespeichert. Der Chat kostet 25 Credits statt 1, weil für jede Antwort ein Sprachmodell über das berechnete Horoskop läuft; eine fehlgeschlagene oder leere Antwort kostet nichts.

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

Dreißig Dasha-Systeme, jetzt nach Familien gruppiert

Damit haben dreißig Systeme einen benannten Endpoint, vorher waren es acht. Die übrigen waren nur über einen String an /api/nakshatra_dasha/ oder /api/raasi_dasha/ erreichbar – die Suche nach „narayana dasha“ fand also nichts. In der Referenz stehen sie jetzt in drei Gruppen: Nakshatra (Planeten), Rashi (Jaimini) und Werkzeuge. Vorher war es eine alphabetische Liste mit fünfunddreißig Einträgen, in der Brahma-Dasha neben Budhi-Gati-Dasha stand.

Bestehendes bleibt unverändert

/api/nakshatra_dasha/ und /api/raasi_dasha/ bleiben unberührt, und die acht schon vorhandenen Dasha-Endpoints verhalten sich genau wie vorher. Jede neue Route delegiert an dieselbe übergeordnete View – die Zahlen sind also zwangsläufig identisch und stammen nicht aus einer Kopie, die auseinanderlaufen könnte. Der Chat-Endpoint ist von den bestehenden /api/ai/-Routen der App getrennt; diese bleiben unverändert.

Was neu ist

POST /api/astro/prashnavali/ram-shalaka/ liefert die 225 Chaupais der Ram Shalaka Prashnavali, jede mit ihrem Devanagari-Buchstaben, dem Chaupai selbst, der Fundstelle im Ramcharitmanas und einer Antwort auf Englisch. /api/astro/prashnavali/hanuman/ liefert die 49 nummerierten Antworten, /api/astro/prashnavali/sai/ die 720 Sai-Antworten und /api/astro/prashnavali/mavji/ die 64 Mavji-Maharaj-Deutungen auf Hindi und Englisch. In der Referenz stehen alle vier unter der neuen Kategorie Avatar-Chakra.

Drei Dinge, die sie anders machen als ihr Vorgänger

Der Filter ist überall optional. /api/astro/chakra/ weist eine sai_prashnavali-Anfrage ohne Zahl ab; die neuen Endpoints liefern dann einfach den ganzen Satz – und so nutzt man Orakeldaten normalerweise: einmal abrufen, cachen, lokal indexieren. Die Einträge kommen als LISTE zurück, mit dem Index an jedem Eintrag, statt als Objekt mit Zahlen-Strings als Keys. So kannst du der Reihe nach iterieren, ohne String-Keys numerisch sortieren zu müssen (sonst lautet die Reihenfolge 1, 10, 100, 11). Und jede Antwort enthält ein count – so unterscheidest du eine Einzelabfrage von einem vollständigen Abruf, ohne in die Nutzdaten zu schauen.

Bestehendes bleibt unverändert

/api/astro/chakra/ bleibt unberührt. Der Endpoint liefert weiterhin alle vier Datensätze über sein Feld keys, antwortet weiterhin im Format {key: data} und gibt weiterhin 400 zurück, wenn bei sai_prashnavali die Zahl fehlt. Hast du ihn schon angebunden, ändert sich für dich nichts – das sind zusätzliche Routen, kein Ersatz.

In der Referenz umbenannt

Aus „KP (Krishnamurti) chart“ und „Krishnamurti paddhati“ wurden „KP chart (cusps, signs and planets)“ und „KP parts (pick with keys)“ – der erste liefert das ganze Horoskop, beim zweiten nennst du die Teile, die du willst. „House lord placements“ und „House lord placement“, die sich nur in einem Buchstaben unterschieden, heißen jetzt „(all 144)“ und „(one pair)“. Zwei Endpoints, die beide „Pancha Pakshi“ hießen, heißen jetzt „(bird activity by hora)“ und „(day in ten yamas)“. Aus „Birth panchanga effects“ und „Birth panchanga readings“ wurden „(reference table)“ und „(your elements)“.

Die Routen bleiben gleich

Es geht nur um Anzeigenamen in der Dokumentation. Jede Route und jedes Feld in Anfrage und Antwort ist genau wie vorher – an deiner Integration musst du nichts ändern. Hast du eine Doku-Seite als Lesezeichen gespeichert, funktioniert die URL weiterhin; nur die Überschrift ist klarer.

Screenshots auf den Referenzseiten

43 Endpoint-Seiten zeigen jetzt einen Screenshot, wie die Daten des Endpoints in einer echten Oberfläche aussehen – Panchang, Choghadiya, der Festkalender, Rückläufigkeiten, elf regionale Kalender, Geburtshoroskope und mehr. Eine Feldtabelle zeigt dir den Aufbau einer Antwort, aber nicht, wofür sie gut ist. Ein Blick auf das Bild klärt meist, ob es der richtige Endpoint ist. Die Doku-Übersicht und die Startseite zeigen dieselbe Auswahl.

Was sich geändert hat

/api/astro/chart/ akzeptiert jetzt das optionale Feld render. Lässt du es weg, ändert sich nichts – die Antwort ist genau wie immer. Setzt du es auf "svg", kommen zu den üblichen vier Feldern zwei weitere hinzu: layout (die Polygonpunkte jeder Haus- oder Zeichenzelle, die Position der Beschriftung und welche Planeten darin stehen) und svg (fertiges Markup, das du direkt in eine Seite einsetzen kannst). Mit chart_style wählst du Nordindisch (die Raute, feste Häuser, wandernde Zeichen) oder Südindisch (das feste Zeichenraster, wandernde Häuser); svg_size, theme, label_style, show_degrees und vier *_color-Felder bestimmen das Aussehen.

Warum das wichtig ist

Ein Horoskoprad aus rohen Längengraden zu bauen ist echte Arbeit – Häusergeometrie, Zeichenrotation, Platzierung der Beschriftungen –, und jeder Integrator hat sie bisher von vorn gemacht. Jetzt ist es ein einziges Feld in einem Aufruf, den du ohnehin sendest. Die Layout-Geometrie ist für alle gedacht, die nativ in React, Canvas, Flutter oder SwiftUI rendern statt unser Markup zu verwenden.

Bestehendes bleibt unverändert

render steht standardmäßig auf "none", und alle anderen neuen Felder haben Standardwerte, die nichts bewirken. Eine Anfrage, die keines davon erwähnt, bekommt nachweislich bytegenau dieselbe Antwort wie vor dieser Änderung – geprüft für jeden Horoskoptyp und jede Option, die dieser Endpoint akzeptiert.

Dashas, die man finden kann

Dreißig Dasha-Systeme haben wir schon vorher berechnet – elf Nakshatra-Dashas und neunzehn Rashi-Dashas, jeweils über mehrere Ebenen. Sie waren aber nur Werte eines dasha_type-Strings bei zwei Endpoints namens nakshatra_dasha und raasi_dasha, und die Suche nach „vimshottari dasha“ fand nichts. Jetzt gibt es benannte Routen: /api/astro/dasha/vimshottari/, /yogini/, /ashtottari/, /chara/, /narayana/, /kalachakra/ und weitere, dazu /api/astro/dasha/systems/, das jedes System mit dem zuständigen Endpoint auflistet. Die beiden ursprünglichen Endpoints bleiben unberührt und funktionieren weiter.

Welche Dasha gerade läuft

/api/astro/dasha/current/ beantwortet die Frage, an der die Zeitleisten-Endpoints scheiterten: Es liefert die Kette ab der Mahadasha abwärts – „Jupiter / Ketu / Merkur“ – mit Beginn und Ende jeder Ebene, wie weit sie schon fortgeschritten ist und wie viele Tage noch bleiben. Bisher musstest du dafür den ganzen Baum abrufen, rekursiv durchlaufen und die Daten in deinem eigenen Code vergleichen.

Traditionelle und hellenistische westliche Astrologie

/api/astro/traditional/dignities/ liefert Domizil, Erhöhung, Triplizität, Term und Dekan für jeden Planeten samt Lillys Punktzahl; /almuten/ nennt für jeden Horoskoppunkt den Planeten mit den meisten Würden; /sect/ sagt, ob es ein Tag- oder Nachthoroskop ist und was daraus folgt; /profections/ liefert die jährliche, monatliche und tägliche Profektion mit dem Jahresherrscher. Alle rechnen tropisch, wie es die Lehre verlangt, und die Antwort nennt die verwendeten Term- und Triplizitätstabellen – denn die Quellen sind sich uneins, und eine Punktzahl nach einer anderen Tabelle ist eine andere Zahl.

Abgeleitete Horoskope und der Mond

Drakonische, harmonische, Antiszien-, heliozentrische und Davison-Horoskope unter /api/astro/western/, dazu /api/astro/lunar/void-of-course/ und /api/astro/lunar/mansions/. Void of Course ist keine Momentaufnahme, sondern eine Vorwärtssuche: Sie läuft bis zum nächsten Zeichenwechsel des Mondes, meldet jeden Aspekt, der noch exakt wird, samt genauem Zeitpunkt, und sagt dir, wann der leere Lauf beginnt und endet.

Chinesische Vier Säulen

/api/astro/chinese/four-pillars/, /bazi/, /zodiac/ und /luck-pillars/. Das chinesische Jahr beginnt mit Lichun um den 4. Februar – nicht am 1. Januar und nicht mit dem chinesischen Neujahr. Das ist ein Monddatum und bestimmt das Fest, nicht das Horoskop. Eine Geburt am 20. Januar 2024 ergibt daher einen Wasser-Hasen, keinen Holz-Drachen. Die Konventionen für die Tagesgrenze und für die wahre Sonnenzeit sind beide Anfragefelder, denn Praktiker halten es unterschiedlich, und jede verändert das Horoskop.

Tarot

/api/astro/tarot/draw/, /spread/, /yes-no/ und /deck/. Jede Ziehung liefert den Seed, aus dem sie entstanden ist. Schickst du diesen Seed zurück, wird die Ziehung exakt wiederholt – dieselben Karten, dieselbe Reihenfolge, dieselbe Ausrichtung. Nur so kannst du eine Legung speichern und erneut anzeigen, statt dem Fragenden auf dieselbe Frage eine andere Antwort zu geben. Sechs benannte Legesysteme bis zum Keltischen Kreuz mit zehn Karten, jede Position beschriftet.

Außerdem neu

/api/astro/eclipse/visibility-path/ zeichnet nach, wo eine Sonnenfinsternis total ist – als Koordinaten, die du auf eine Karte übertragen kannst, mit dem Punkt der größten Verfinsterung und ihrer Saros-Reihe. Neun weitere Endpoints machen Berechnungen einzeln zugänglich, für die man bisher wissen musste, welche Keys man bei einem größeren Endpoint abfragt: Ashtakavarga-Prastara und -Sodhana, Tajika-Aspekte und -Yogas, Horizont- und Äquatorkoordinaten der Planeten, Mondbeleuchtung, Vasa-Segmente und Cazimi.

Bestehendes bleibt unverändert

Jeder hier hinzugekommene Endpoint ist eine neue Route. Bei keinem bestehenden Endpoint haben sich Anfrage-Body, Antwortaufbau oder Feldnamen geändert, und kein Endpoint wurde entfernt oder umbenannt. Die Preise bleiben gleich: Ein erfolgreicher Aufruf kostet einen Credit, egal was er liefert.

Was sich geändert hat

Endpoints wie /api/astro/sunrise/, /api/astro/tithi/, /api/astro/navamsa/ und /api/astro/rahu-kaal/ erwarten die üblichen Geburts- oder Datumsfelder und liefern nur das, wonach sie benannt sind. Die bestehenden kombinierten Endpoints bleiben unverändert und funktionieren genau wie bisher.

Warum das wichtig ist

Um eine Sonnenaufgangszeit anzuzeigen, musst du keine komplette Panchang-Antwort mehr anfordern, bezahlen und parsen. Kleinere Payloads, weniger Mapping-Code und ein Anfrage-Body, den man auf einen Blick versteht.

So legst du los

Stöber in der Referenz und schick die Beispielanfrage mit deinem Schlüssel im Header X-API-Key. Die Preise bleiben gleich: Ein erfolgreicher Aufruf kostet einen Credit, egal was er liefert.

Was sich geändert hat

Die Suche findet Funktionen, nicht nur Endpoint-Namen. Wer „manglik“ eintippt, findet den Dosha-Endpoint, obwohl „manglik“ nicht in seinem Namen vorkommt – und das Ergebnis zeigt dir, welches Feld gepasst hat.

Warum das wichtig ist

Hinter der Endpoint-Liste stecken mehrere Hundert einzelne Felder. Ohne Suche über die Feldnamen musstest du Endpoints einzeln öffnen und ihre Antworten lesen, um das richtige zu finden.

Was sich geändert hat

Der MCP-Server occult-api stellt Endpoint-Suche, Endpoint-Beschreibungen und Aufrufe als Tools bereit. Gib ihm deinen API-Schlüssel, und ein Assistent findet den richtigen Endpoint und ruft ihn direkt auf.

Warum das wichtig ist

So probierst du die API am schnellsten an einer echten Frage aus, bevor du dich festlegst, etwas zu bauen. Gleichzeitig ist der Server eine funktionierende Referenzimplementierung des Anfrageformats.

Was sich geändert hat

Jede Endpoint-Seite führt direkt in den Playground, die Beispielanfrage ist schon ausgefüllt. Änder Breitengrad, Datum oder Ayanamsa und schick sie erneut.

Warum das wichtig ist

Eine Beispielantwort zeigt dir, wie die Daten aufgebaut sind. Erst deine eigenen Eingaben zeigen dir, ob sie deine Frage beantworten.

Was sich geändert hat

Registrier dich, erzeug einen Schlüssel und schick ihn im Header X-API-Key mit. Credits werden pro erfolgreichem Aufruf abgezogen – eine fehlgeschlagene Anfrage kostet nie etwas.

Warum das wichtig ist

Keine Preisliste pro Endpoint, über die du grübeln musst. Gerechnet wird mit NASA-JPL-Ephemeriden und einem vollständigen Satz klassischer und moderner Ayanamsas.