Felderformatiere

Last updated 7. Nov. 2026 Als Markdown öffnen Agenten-Setup

Ein Modell, das den Feldnamen errät, erhält entweder 400 oder, schlimmer noch, eine sichere Antwort mit einer anderen Karte. Unten steht der genaue Vertrag.

Körper der Kartenanfrage

Feld	Typ und Format	Erforderlich
`date`	`YYYY-MM-DD`, und das muss ein realer Kalendertag sein	ja
`time`	`HH:mm:ss`	ja, oder `timeUnknown: true`
`timezoneOffset`	Zahl, Stunden von UTC, z.B. `5.75`	nein, standardmäßig `0` (UTC)
`timezone`	IANA-Zonenname, z.B. `Europe/Kyiv`, oder `auto`	nein, und wenn gesendet, überschreibt `timezoneOffset`
`latitude`	Dezimale Grad, Nord positiv	ja
`longitude`	Dezimale Grad, Ost positiv	ja
`houseSystem`	ein Buchstabe, standardmäßig `P`	nein
`city`	Zeichenkette, nur Beschriftung	nein
`zodiacType`	`tropical` oder `sidereal`	nein

Kurzschreibweisen werden abgelehnt

lat, lon, lng, long, tz, tzOffset, utcOffset, gmtOffset, timeZone, time_zone führen zu 400 INVALID_FIELD mit dem korrekten Feldnamen:

{ "error": { "code": "INVALID_FIELD",
  "message": "Unsupported field \"tz\". Rename it to \"timezoneOffset\" (numeric hours from UTC, e.g. 5.75; a zone name goes in timezone)." } }

Groß-/Kleinschreibung und Trennzeichen sind nicht erlaubt: TZ_Offset und tzoffset werden ebenso abgelehnt. Alle gefundenen Felder werden gleichzeitig gemeldet, nicht nur das erste, sodass du sie auf einmal korrigieren kannst.

Der Grund ist streng: Vor dieser Prüfung gab ein Feld, das die API nicht gelesen hatte, stillschweigend den Offset 0 zurück, und die Antwort war eine sichere Karte für UTC. Ein Offset von drei Stunden entspricht etwa 45° Aszendent, also einem anderen aufsteigenden Zeichen, und das ohne Warnung.

`timezone`: Zonenname statt Offset

Der Offset muss der sein, den die Uhren genau an diesem Datum hatten, und man kann ihn manuell leicht falsch angeben: Kiew im Mai 1990 lebte nach der Moskauer Sommerzeit, UTC+4, nicht +3. Sende timezone und der Server nimmt den Offset aus der Zeitzonendatenbank, inklusive Sommerzeit.

{ "date": "1990-05-15", "time": "14:30:00", "timezone": "Europe/Kyiv",
  "latitude": 50.45, "longitude": 30.52 }

auto bestimmt die Zone anhand von latitude und longitude. In Grenznähe ist der Name genauer.
Wenn timezone und timezoneOffset zusammen gesendet werden, gilt timezone. input.timezoneOffset in der Antwort zeigt den tatsächlich verwendeten Offset.
Die Zeit, die zweimal vorkam (wenn die Uhren zurückgestellt wurden), wird beim ersten Mal genommen. Die Zeit, die nicht existierte (wenn die Uhren vorgespult wurden), erhält den Offset, der vor der Umstellung galt.
Ohne time (nur Datum oder timeUnknown: true) wird die Zone zur lokalen Mittagszeit ermittelt.
Abgelehnt mit 400 INVALID_FIELD: leerer Wert, Abkürzungen wie EST oder PST, Offset als Text wie +03:00, Namen, die nicht in der Datenbank sind, und auto ohne Koordinaten. UTC und GMT werden akzeptiert.
Jedes Objekt wird separat verarbeitet, sodass chart1 und chart2 in unterschiedlichen Zonen sein können.

`houseSystem`: Buchstabe, kein Name

Genau diese 25 Einbuchstaben-Codes werden akzeptiert (die gleichen wie in swetest):

P K R C E W B M O A T V D F G H I i L N Q S U X Y

Die Groß-/Kleinschreibung ist bedeutend: I ist Sunshine nach McRae, i nach Trundle. Der Systemname ("Placidus", "Koch") führt zu 400. Früher funktionierte es zufällig, weil die Engine aus dem String nur den ersten Buchstaben liest, und aus demselben Grund gab "Zodiac" stillschweigend Placidus zurück.

Unbekannte Geburtszeit

Statt einer erfundenen Mittagszeit übermittle timeUnknown: true und übermittle kein time. Dann kommen houses, houseAspects, chartSect und siderealTime als null zurück, nicht erfunden. Details: API-Konventionen.

Unbekannte Schlüssel werden nicht abgelehnt

Der Body akzeptiert zusätzliche Felder stillschweigend: ein unbekannter Schlüssel wird einfach ignoriert. Daher wird ein Tippfehler im Feldnamen, der nicht in der obigen Ablehnungsliste steht, nicht bemerkt. Vergleiche die Spezifikation: /v1/openapi.json.

Weiter