Integrationsleitfaden

Die Booking.com-API: wie der Zugang funktioniert und was sie dir wirklich erlaubt

Geschrieben für Entwickler und technische Gründer, die man auf die Konnektivitäts-APIs von Booking.com angesetzt hat. Hier geht es darum, wie Partnerbenennung und Verbindung pro Unterkunft funktionieren, um das Datenmodell, von dem alles andere abhängt, und um die zwei, drei Verhaltensweisen, durch die ein Preis-Update bei Booking.com auf dem Papier klappt und in der Praxis nichts ändert.

Was die Booking.com-API ist

Die APIs von Booking.com sind für Konnektivitätsanbieter gebaut: die Channel-Manager und Property-Management-Systeme, die Unterkünfte für viele Objekte gleichzeitig synchron halten. Es sind keine Verbraucher-APIs, es gibt keine öffentliche Such- oder Buchungsschnittstelle für Dritte und kein Entwicklerportal, bei dem du dich anmeldest.

Praktisch sind es mehrere Produktflächen unter einer Partnerschaft – Verfügbarkeit und Preise, Buchungen, Einrichtung von Unterkünften und Zimmern, Inhalte, Nachrichten, Bewertungen und Gebühren. Sie verhalten sich unterschiedlich, werden getrennt freigegeben, und Teile der älteren Schnittstelle sind XML statt JSON. Wenn du von Airbnb kommst, gilt fast keine deiner Annahmen mehr.

Wie bekomme ich Zugang zur Booking.com-API?

Drei Ebenen, vergeben von drei verschiedenen Parteien – genau wie bei Airbnb, nur anders geformt.

1. Booking.com benennt dein Unternehmen als Konnektivitätsanbieter. Du bewirbst dich, wirst geschäftlich und technisch geprüft, und es gibt einen Zertifizierungsschritt für die Schnittstellen, die du nutzen willst. Das ist eine Beziehung auf Unternehmensebene, die Monate dauert.
2. Du bekommst Zugangsdaten für ein Maschinenkonto. Anders als die OAuth-Tokens pro Gastgeber bei Airbnb handelt ein einziges Maschinenkonto für jede mit dir verbundene Unterkunft. Diese eine Zugangsberechtigung ist der Wirkungsradius deines ganzen Geschäfts, und sie ändert, wie du Fehler liest – siehe den Hinweis unten.
3. Jede Unterkunft verbindet dich in ihrem eigenen Extranet. Der Gastgeber meldet sich im Booking.com-Extranet an, öffnet die Liste der Konnektivitätsanbieter, sucht deinen Anbieter nach Namen und klickt auf Verbinden. Bis er das tut, kann dein Maschinenkonto diese Unterkunft überhaupt nicht sehen. Er braucht dafür auch seine numerische Hotel-ID.

Mit Repull ist die Gastgeberseite eine einzige gehostete Session mit deinem Branding; der Gastgeber erledigt den Schritt im Extranet und fügt seine Hotel-ID ein, und du bekommst eine Verbindung zurück. Die Anleitung findest du unter Booking.com verbinden.

curl -X POST 'https://api.repull.dev/v1/connect/booking' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "redirectUrl": "https://yourapp.com/connected" }'

Unterkünfte, Zimmer und Ratenpläne

Versteh das, und der Rest von Booking.com ergibt sich. Versteh es falsch, und jeder Endpunkt wirkt willkürlich.

Booking.com property   "hotel_id": 5432505        ← the building
└── room               "roomBookingId": 543250501 ← what a guest books
    └── rate plan      "rateId": 98765            ← the terms it sells on
        └── price at an occupancy                ← what you actually write

Eine Unterkunft ist ein Gebäude. Zimmer sind das, was Gäste buchen. Ratenpläne sind die geschäftlichen Bedingungen, zu denen ein Zimmer verkauft wird, und ein Preis gehört zu einem Tupel (Zimmer, Ratenplan, Datum, Belegung) – nicht zu einer Nacht. Eine Villa mit einem Schlafzimmer ist der einfache Fall; ein Aparthotel mit zwanzig Einheiten ist eine einzige Unterkunft mit zwanzig Zimmern, und das ist normal, kein Randfall.

Dieselbe Einheit kann auch unter mehr als einer Booking.com-Unterkunft auftauchen, meist weil sie im Lauf der Zeit neu eingestellt wurde, und ein Zimmer, das keinem deiner Inserate zugeordnet ist, gehört zu nichts – seine Buchungen haben keinen Landeplatz. Ordne Zimmer im Verbindungsablauf zu, nicht danach.

Kann ich über die Booking.com-API Preise ändern?

Ja, und das ist die meistgenutzte Fläche der ganzen Partnerschaft. Du schreibst einen Preis für ein Zimmer in einem Ratenplan über einen Datumsbereich, optional mit Aufenthalts- und Anreiseeinschränkungen im selben Aufruf.

curl -X PUT 'https://api.repull.dev/v1/channels/booking/availability' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "rates",
    "property_id": "1234567",
    "updates": [{
      "roomId": "123456701",
      "rateId": "98765",
      "dateRange": { "start": "2026-11-04", "end": "2026-11-04" },
      "price": 210,
      "currency": "USD",
      "occupancy": 4
    }]
  }'

roomId und rateId kommen aus GET /v1/channels/booking/properties/{id}/rooms. Alles andere an der Anfrage – und das ist mehr, als du erwartest – steht unter Booking.com-Preise aktualisieren.

Warum hat mein Preis-Update bei Booking.com nichts bewirkt?

Das ist die Frage, die Leute auf diese Seite bringt, und es gibt zwei unabhängige Antworten. Beide sehen nach Erfolg aus.

Die Belegung ist Teil des Schlüssels, keine Präferenz

Booking.com speichert nicht „den Preis dieser Nacht“. Es speichert einen Preis für eine Nacht für eine Personenzahl in einem Ratenplan. Die Belegung, die du schickst, entscheidet also, welchen Preis du überschreibst. Jeder Betrag geht mit einer Belegung raus, ob du sie angibst oder nicht.

• Gib eine Belegung über dem Maximum an, für das der Ratenplan Preise hat, und Booking.com nimmt die Anfrage an und verwirft den Betrag stillschweigend. Die Nacht behält ihren alten Wert – oft 0.00 –, und die Bestätigung ist Byte für Byte identisch mit einem erfolgreichen Schreibzugriff.
• Gib eine darunter an, und du bekommst ein 400. Der veröffentlichte Preis ändert sich nicht.
• Die Gästekapazität deines eigenen Inserats ist nicht die maßgebliche Zahl. Maßgeblich ist die, die Booking.com für diesen Ratenplan hat. Lies sie zurück, statt sie abzuleiten.

Repull ermittelt die Belegung aus den eigenen Daten von Booking.com für das Paar (Zimmer, Ratenplan), wenn du sie weglässt, gibt dir den verwendeten Wert und seine Herkunft zurück und lehnt den Schreibzugriff mit einem 422 ab, wenn sie sich nicht ermitteln lässt. Ein Betrag wird nie blind gesendet.

Die Quittung ist keine Bestätigung

Booking.com beantwortet einen Raten-Schreibzugriff meist mit einer nackten Quittung ohne Status pro Datum. Der Body ist wörtlich:

{"ok": ""}

Datumsbereiche und die Nacht, die du verlierst

Darunter nimmt das XML für Verfügbarkeit und Preise einen Bereich, dessen to-Datum nicht geschriebenwird – eine exklusive Grenze, so wie ein Abreisedatum die letzte Nacht ausschließt. Die meisten Kalender, die du vorher integriert hast, behandeln beide Enden als Nächte. Die natürliche Lesart von „1. bis 7. August“ sind also sieben Nächte, auf der Leitung sind es sechs, und die Nacht, die du unbemerkt verlierst, ist die letzte jedes Bereichs, den du schreibst.

Es ist eine einzeilige Umrechnung und ein wochenlanger Bug, weil er dich immer nur die letzte Nacht kostet: Der Kalender sieht weitgehend richtig aus, eine Stichprobe passt, und die Lücke zeigt sich als verpasste Buchung statt als Fehler.

Inventar ist ein eigener Schreibzugriff

Eine Nacht zu bepreisen öffnet sie nicht für den Verkauf, und sie zu öffnen gibt ihr keinen Preis. Verfügbare Zimmer und der Verkaufsstopp sind ein eigener Update-Typ; sie in einem Preis-Update mitzuschicken wird abgelehnt, statt still verworfen.

# Close a night: zero rooms to sell, stop-sell on
curl -X PUT 'https://api.repull.dev/v1/channels/booking/availability' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "availability",
    "property_id": "1234567",
    "updates": [{
      "roomId": "123456701",
      "rateId": "98765",
      "dateRange": { "start": "2026-11-04", "end": "2026-11-04" },
      "availableRooms": 0,
      "closed": true
    }]
  }'

Details unter Verfügbarkeit an Booking.com senden. Wenn du lieber einmal einen Kalender schreibst und ihn auf allen verbundenen Kanälen landen lässt, ist das PUT /v1/availability/{propertyId}, mit PATCH /v1/availability/batch für viele Unterkünfte auf einmal.

Einschränkungen, die es gibt – und die es nicht gibt

Mindest- und Höchstaufenthalt (nach Aufenthaltsdatum und nach Anreisedatum), Anreisesperre und Abreisesperre gibt es wirklich, und sie lassen sich pro Zimmer, Ratenplan und Datumsbereich setzen.

Mehrere Einschränkungen, die Leute erwarten, sind in der Benachrichtigung, die Booking.com akzeptiert, schlicht nicht enthalten – darunter eine exakte Aufenthaltsdauer bei Anreise und eine minimale oder maximale Vorausbuchungsfrist. Das richtige Verhalten ist, sie laut abzulehnen. Eine Einschränkung, die angenommen und dann nicht gesendet wird, ist der eine Fehler, den du in keiner Antwort sehen kannst, deshalb antwortet Repull mit 422 und nennt das Feld, statt es zu verwerfen. Siehe restriction_not_supported und Mindestaufenthalt und Einschränkungen.

Buchungen, Nachrichten, Bewertungen und Gebühren

• Buchungen – auflisten und quittieren. Das Quittieren ist keine optionale Buchhaltung: Neue Buchungen bleiben in einer Warteschlange, bis du sie bestätigst, und ein Partner, der nie quittiert, liest immer wieder dieselben Buchungen. Buchungen.
• Nachrichten – Unterhaltungen auflisten und senden. Schmaler als die Thread-Schnittstelle von Airbnb; kein Bearbeiten, keine Reaktionen, kein Lesestatus. Gästenachrichten.
• Bewertungen – auflisten und antworten. Bewertungen.
• Gebühren und Kosten – lesen und schreiben. Gebühren und Kosten.
• Einrichtung und Go-live – die juristische Einheit anlegen, die Bereitschaft prüfen, Kontakte und Richtlinien setzen und eine Unterkunft für den Verkauf öffnen. Einrichtung und Go-live.
• Keine Änderungen. Booking.com hat kein Gegenstück zum Änderungsablauf von Airbnb. Datums- und Preisänderungen an einer bestehenden Buchung sind keine API-Operation.

Die Funktionsmatrix stellt Airbnb und Booking.com nebeneinander und markiert Teilweises als teilweise, statt es aufzurunden.

Warum gibt die Content-API 403 zurück?

Weil Inhalte eine eigene Produktfläche mit eigener Berechtigung und eigenem Basispfad sind, getrennt von Verfügbarkeit, Preisen und Buchungen. Eine Unterkunft kann voll live sein – Buchungen annehmen, jeden Preis- und Verfügbarkeitszugriff akzeptieren, den du schickst –, während jeder Content-Aufruf für dieselbe Unterkunft 403 liefert.

Wenn das passiert, verdächtigt man reflexhaft den Token, dann die Unterkunfts-ID, dann die Extranet-Berechtigungen des Gastgebers. Meist ist es nichts davon. Die Funktion wurde dir für diese Fläche nicht freigegeben, und Neuverbinden ändert das nicht. Klär, welche Funktionen deine Partnerschaft wirklich umfasst, bevor du Foto- oder Beschreibungsverwaltung in ein Release einplanst.

Inhalte decken, wo verfügbar, Fotos, Beschreibungen, Ausstattung, Einrichtungen und Richtlinien ab, auf Unterkunfts- oder Zimmerebene – und Booking.com prüft Textänderungen, bevor sie erscheinen, ein Schreibzugriff ist also der Anfang eines Prozesses, nicht sein Ende. Inhalte und Fotos.

Was es heißt, das selbst zu bauen

1. Partnerbenennung und Zertifizierung. Monate, mit geschäftlicher Prüfung und einer technischen Zertifizierung pro Fläche. Du kannst keinem Kunden einen Termin versprechen.
2. Ein Sicherheitsmodell mit geteilten Zugangsdaten. Ein Maschinenkonto für jede Unterkunft, die du betreust. Rotation, Speicherung und ein Fehler-Klassifizierer, der sorgfältig genug ist, dass ein globales 401 während eines Ausfalls nicht alle deine Kunden auf einmal trennt.
3. Das Modell und die Zuordnung. Von Unterkünften zu Zimmern, zu Ratenplänen und zu deinen eigenen Inseraten, inklusive Unterkünften mit mehreren Zimmern, neu eingestellten Einheiten und nicht zugeordneten Zimmern, deren Buchungen nirgendwohin können.
4. Überprüfung von Schreibzugriffen. Weil die Quittung nichts beweist, liest eine korrekte Integration zurück und gleicht ab. Das ist ein zusätzlicher Aufruf, eine Wartezeit und eine Zustandsmaschine – auf deinem heißesten Pfad.
5. Konventionen, die nicht zusammenpassen. Exklusive Datumsgrenzen, belegungsabhängige Preise, Inventar getrennt von Preisen, Einschränkungen, die es nicht gibt, XML, wo du JSON erwartet hast.
6. Ständige Brüche. Wie bei jeder Partner-API: Das geht nie auf null.

Ehrlich zusammengefasst: Booking.com ist eine schwerere Integration als Airbnb und teilt fast keine seiner Annahmen – anderes Authentifizierungsmodell, anderes Datenmodell, andere Datumssemantik, andere Definition eines erfolgreichen Schreibzugriffs. Teams, die gerade mit Airbnb fertig sind, unterschätzen es jedes Mal. Der Leitfaden zur Airbnb-API ist der Vergleich.

Wo Repull ins Spiel kommt

Repull ist eine REST-API mit einem Schlüssel für Booking.com, Airbnb, Vrbo, Plum Guide und die Property-Management-Systeme, die Gastgeber bereits nutzen. Wir halten die Partnerbeziehungen; Unterkünfte verbinden sich selbst über einen gehosteten Ablauf mit deinem Branding.

• Ein gehosteter Verbindungsablauf. POST /v1/connect/{provider}, mit der Zimmerzuordnung direkt darin. Connect.
• Schreibzugriffe, die dir die Wahrheit sagen. Überprüfung per Zurücklesen bei Preisen, ermittelte und zurückgegebene Belegung, nicht unterstützte Einschränkungen abgelehnt statt verworfen, an beiden Enden inklusive Datumsbereiche.
• Ein Kalender-Schreibzugriff für alle Kanäle. PUT /v1/availability/{propertyId} schickt Preis und Verfügbarkeit an jeden Kanal, mit dem eine Unterkunft verbunden ist.
• Webhooks mit Zustellverlauf und Replay statt eigener Benachrichtigungstechnik pro Kanal. Webhooks.

Fang mit dem Quickstart an oder lies die Kanal-Übersicht. Wenn du eine Plattform bist, die das für ihre eigenen Kunden einbaut statt für sich selbst, deckt der Leitfaden für Plattformen dieses Modell Frage für Frage ab.

Wenn die Unterkünfte, die du integrierst, schon in einem Property-Management-System liegen, ist das ein zweites, eigenes Problem: Ein PMS gibt dir seine Sicht auf eine Buchung, nicht die API des Kanals. Die Leitfäden zu Guesty, Hostaway, Hospitable, Lodgify und OwnerRez zeigen, was jedes davon bereitstellt, und die Abdeckungsmatrix hat sie alle. Ein Schlüssel deckt gleichzeitig eine PMS-Verbindung und eine direkte Kanalverbindung ab.

Häufige Fragen