Blockierungen über die Daten-API lesen und setzen
Wie du Sperren über die Daten-API erkennst (kind), filterst, anlegst und aufhebst, wohin sie weitergegeben werden und warum Pending dafür nicht taugt.
Aktualisiert am 19. Oktober 2026
Über die Daten-API sind Sperren dieselben Objekte wie Buchungen; GET /api/v1/bookings/ liefert sie mit. Du erkennst sie am Feld kind:
kindistreservation(echter Aufenthalt) oderblock(gesperrter Zeitraum: Eigentümerblock, Wartung, vom Kanal übernommene Sperre, Puffernacht, Sperre einer verknüpften Einheit).statussagt es dir nicht. Eine Sperre wird als bestätigt gespeichert, sonst fiele sie aus den Kanalkalendern, und kommt deshalb ebenfalls alslivean.- Filtern mit
?kind=reservation,?kind=blockoder?kind=all(Standard). - Anlegen mit
kind: "block"aufPOST /api/v1/bookings/create, dazuaccommodation(die Unit-ID), Zeitraum und optionalblock_reason. Aufheben mitDELETE /api/v1/bookings/{id}. kindundblock_reasonlassen sich nachträglich nicht ändern: aus einer Buchung wird keine Sperre.
Eine Sperre aus der API sperrt die Nächte auf den über Channex verbundenen Portalen wie eine Sperre aus dem Kalender. Ist ein PMS verbunden und dort „Buchungen an PMS senden“ an, geht sie auch an dein PMS, und beim Aufheben wird sie dort wieder entfernt (siehe Buchungen an dein PMS senden).
Unit-IDs für den Parameter accommodation, im Bereich „Deine Units“
Nimm dafür nicht den Status „Pending“ oder „Blockiert“. Beide gelten innerhalb von Xentra als belegt, werden aber nicht an deine angebundenen Portale weitergegeben: dein Kalender wäre zu, und Booking.com verkauft die Nächte weiter, ohne Fehlermeldung. Die API weist beide Werte deshalb mit 400 zurück. Zum Sperren nimm kind: "block", für eine unverbindliche Anfrage den Status Anfrage.
Mehr zur API: siehe Daten-API: Schlüssel, Zugriff und Dokumentation.