Methodik

Die Planetenpositionen werden aus Ephemeridendaten von NASA JPL berechnet – aus dem kompletten 105-MB-Datensatz, nicht aus einer gekürzten Fassung, mit 735 Fixsternen und für die Jahre 500–2999 n. Chr. Nichts wird aus einer Tabelle vorberechneter Almanachwerte interpoliert, und nichts kommt aus einem Cache: Jede Antwort wird für genau den Zeitpunkt und die Koordinaten aus deiner Anfrage berechnet.

Dieser Zeitraum ist in zwei ganz konkreten Fällen wichtig: bei historischen Horoskopen und bei langfristigen Dasha- und Transit-Scans, die Jahrzehnte in die Zukunft reichen. Eine Bibliothek, die nur die Gegenwart abdeckt, wird an den Rändern unbemerkt ungenau.

Derselbe Rechenkern betreibt Yoga Panchang, unsere kostenlose Panchang- und Jyotish-Website. Die Werte, die ihre Leser jeden Tag sehen, stammen also aus dem hier beschriebenen Code.

Wenn zwei vedische Berechnungen voneinander abweichen, liegt das meist nicht an der Arithmetik, sondern am Ayanamsa. Die indischen Traditionen sind sich hier wirklich nicht einig, und schon ein Grad Unterschied schiebt einen Planeten über eine Nakshatra-Grenze.

Deshalb bieten wir 48 Ayanamsas an – die Surya-Siddhanta-Familie, True Citra, True Revati, True Pushya, Raman, KP, Yukteshwar und weitere –, und du kannst jedes davon nach Grad, Minute und Sekunde korrigieren. Wir liefern nicht ein einziges aus und erklären es zum richtigen. Weicht unser Ergebnis von einer anderen Quelle ab, prüf zuerst, ob beide dasselbe Ayanamsa verwenden.

Das können die meisten API-Dokumentationen nicht von sich behaupten: Unsere Referenz ist nicht von Hand geschrieben. build_api_catalogue erzeugt sie direkt aus den Serializern, und verify_api_catalogue prüft sie anschließend an einem laufenden Server. Dabei wird jede dokumentierte Beispielanfrage abgeschickt und kontrolliert, ob sie mit 2xx antwortet.

Das Ergebnis ist genau das, worauf es ankommt: 255 der 299 Endpoint-Seiten zeigen eine echte, aufgezeichnete Antwort und keine erfundene. Die übrigen sind als noch nicht verifiziert gekennzeichnet, statt als funktionierend ausgegeben zu werden. Ein Feld kann nicht still und leise aus der Doku verschwinden, wie es bei einer von Hand gepflegten Tabelle passiert. Ändert sich ein Serializer, ohne dass die Doku neu erzeugt wird, schlägt die Prüfung fehl – und es wird keine Falschaussage veröffentlicht.

Aus demselben Katalog entstehen auch die OpenAPI-Spezifikation, die Postman-Collection und llms.txt. Alle vier beschreiben damit zwangsläufig dieselbe API.

Das Backend hat 1.783 Testfunktionen in 87 Modulen. Am gründlichsten testen sie die Abrechnung, denn dort kostet ein Fehler echtes Geld. Geprüft wird: dass ein erfolgreicher Aufruf genau das abbucht, was der Endpoint kostet; dass ein 4xx und ein 5xx nichts abbuchen; dass zwei gleichzeitige Aufrufe um den letzten Credit das Guthaben nicht ins Minus drücken können; und dass das Buchungsjournal nach einer zufälligen Folge von Gutschriften und Abbuchungen mit dem Guthaben übereinstimmt.

Wir nennen 62 ms im Median und 76 % unter 100 ms. Diese Werte entstehen, indem wir am 22. Oktober 2026 254 veröffentlichte Beispiele mit jeweils eigener Beispielanfrage an einer lokal laufenden Instanz der API aufrufen – einmal zum Aufwärmen, dann einmal mit Zeitmessung –, nicht, indem wir einen schnellen Endpoint stoppen und großzügig runden. Der KI-Chat ist ausgenommen: Seine Zeit ist die des Sprachmodells.

Deshalb sagen wir auch ganz offen: Einige wenige Endpoints sind deutlich langsamer, und das steht so in der Doku. Ein kompletter Varshaphal-Scan oder ein Jahr Raasi-Dasha dauert Sekunden statt Millisekunden, weil hier ein Zeitraum durchsucht und nicht bloß ein Wert nachgeschlagen wird. Ein Median verdeckt das – die Verteilung daneben zeigt es.

Median   62 ms      die Hälfte der Endpoints ist schneller
<100 ms  76 %       der Großteil normaler Abfragen
langsam  Sekunden    aufwendige Scans – in der Referenz genannt

Zwei Dinge würden wir gern veröffentlichen, haben es aber noch nicht getan. Wir sagen das lieber offen, als dich etwas anderes vermuten zu lassen:

• Ein unabhängiger Positions-Benchmark. Wir rechnen mit Ephemeridendaten von JPL, haben aber noch keinen Vergleich unserer Ergebnisse mit JPL Horizons über viele Daten und Himmelskörper veröffentlicht – samt Abweichungen und Code zum Nachrechnen. Bis dahin heißt unsere Genauigkeitsangabe „aus dieser Quelle berechnet“, nicht „mit dieser Toleranz verifiziert“.
• Langfristige Verfügbarkeit. Die Verfügbarkeit wird erst seit Oktober 2026 auf der Statusseite veröffentlicht, daher gibt es noch keine lange Historie, die wir anführen könnten. Wozu wir uns verpflichten, steht unter Transparenz.

Beides steht auf unserer Liste. Schwer ist keins davon – aber wir machen es lieber richtig als ungefähr.

Der Playground schickt echte Aufrufe mit deinem eigenen Schlüssel, und fehlgeschlagene Aufrufe kosten nichts. So kannst du unsere Ergebnisse mit jeder Quelle vergleichen, der du schon vertraust. Findest du eine Abweichung, die sich nicht mit dem Ayanamsa erklären lässt, wollen wir davon erfahren.