Konzepte
Vier Dinge, die du vorher wissen solltest
Vier Festlegungen, die das Verhalten der API bestimmen. Sie weichen von verbreiteten Annahmen ab.
Ein Objekt ist ein Einheiten-Typ
Ein property ist genau ein Typ: ein Zimmertyp im Hotel oder ein Ferienobjekt. Darunter hängen seine Einheiten (units) — im Normalfall genau eine, bei fünf gleichen Studios eben fünf. Verkauft wird die Einheit, geführt und bepreist wird der Typ.
Verfügbarkeit ist deshalb eine ZAHL (units_available), kein Ja/Nein. Ein Hotel mit 8 Twin- und 4 Double-Zimmern hat zwei Objekte mit 8 bzw. 4 Einheiten — nicht ein Objekt mit 12 Zimmern.
Jeder Betrag trägt seine Währung
Es gibt keinen Standardwert. Jedes Objekt hat eine Währung, und jeder Betrag in einer Antwort nennt sie mit.
Fehlt die Währung an einem Objekt, ist das ein Datenfehler und der Aufruf schlägt mit 422 fehl — es wird kein „EUR“ eingesetzt. Beim Buchen muss deine Währung zur Währung des Objekts passen.
Zwei verschiedene Zeitpunkte
booked_at ist der Zeitpunkt der Buchung beim Gast — aus der Quelle des Portals, null, wenn das Portal ihn nicht liefert. received_at ist der Eingang in diesem System.
Sortiere „neueste zuerst“ über booked_at, nicht über received_at: bei einem Sammel-Import tragen Dutzende Buchungen dieselbe Sekunde. Zeitstempel sind UTC, Datumsfelder sind Kalendertage in der Zeitzone des Objekts.
Sichtbarkeit gilt je Kanal
Es gibt kein globales „veröffentlicht“. Ein Objekt ist auf dem Marktplatz sichtbar, auf der eigenen Website, über die Portale — jeweils einzeln schaltbar.
Verkäuflich ist ein Objekt nur, wenn drei Dinge zusammenkommen: status = active, der Kanal ist an, und es gibt freie Einheiten. Ein Verkaufsstopp wirkt dagegen über ALLE Kanäle.