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:

  • kind ist reservation (echter Aufenthalt) oder block (gesperrter Zeitraum: Eigentümerblock, Wartung, vom Kanal übernommene Sperre, Puffernacht, Sperre einer verknüpften Einheit).
  • status sagt es dir nicht. Eine Sperre wird als bestätigt gespeichert, sonst fiele sie aus den Kanalkalendern, und kommt deshalb ebenfalls als live an.
  • Filtern mit ?kind=reservation, ?kind=block oder ?kind=all (Standard).
  • Anlegen mit kind: "block" auf POST /api/v1/bookings/create, dazu accommodation (die Unit-ID), Zeitraum und optional block_reason. Aufheben mit DELETE /api/v1/bookings/{id}.
  • kind und block_reason lassen 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“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.

Passende Artikel