Przewodnik integracji

API Booking.com: jak działa dostęp i co naprawdę pozwala zrobić

Napisany dla programisty albo technicznego foundera, którego skierowano do API łączności Booking.com. Wyjaśnia, jak działa status partnera i podłączanie pojedynczych obiektów, model danych, od którego zależy cała reszta, oraz te dwa czy trzy zachowania, przez które zmiana stawek w Booking.com udaje się na papierze, a w praktyce niczego nie zmienia.

Czym jest API Booking.com

API Booking.com są stworzone dla dostawców łączności: channel managerów i systemów do zarządzania obiektami, które synchronizują zakwaterowanie w imieniu wielu obiektów naraz. To nie są API dla konsumentów, nie ma publicznego interfejsu wyszukiwania ani rezerwacji dla firm trzecich i nie ma portalu dla deweloperów, w którym można się zarejestrować.

W praktyce to kilka powierzchni produktu w ramach jednego partnerstwa – dostępność i stawki, rezerwacje, konfiguracja obiektów i pokoi, treści, wiadomości, opinie i opłaty. Zachowują się różnie, są przyznawane osobno, a część starszego interfejsu to XML, a nie JSON. Jeśli przychodzisz z Airbnb, prawie żadne z twoich założeń się nie sprawdzi.

Jak uzyskać dostęp do API Booking.com?

Trzy warstwy, przyznawane przez trzy różne strony – dokładnie jak w Airbnb, ale w innym kształcie.

1. Booking.com wyznacza twoją firmę na dostawcę łączności. Składasz wniosek, przechodzisz ocenę biznesową i techniczną, a dla interfejsów, z których chcesz korzystać, jest etap certyfikacji. To relacja na poziomie firmy, która trwa miesiące.
2. Dostajesz dane logowania do konta maszynowego. W przeciwieństwie do tokenów OAuth dla każdego gospodarza w Airbnb jedno konto maszynowe działa w imieniu wszystkich obiektów podłączonych do ciebie. Te jedne dane logowania to zasięg skutków dla całego twojego biznesu i zmieniają sposób, w jaki czytasz błędy – zobacz uwagę poniżej.
3. Każdy obiekt podłącza cię w swoim Extranecie. Gospodarz loguje się do Extranetu Booking.com, otwiera listę dostawców łączności, wyszukuje twojego dostawcę po nazwie i klika Połącz. Dopóki tego nie zrobi, twoje konto maszynowe w ogóle nie widzi tego obiektu. Będzie też potrzebował swojego numerycznego Hotel ID.

Z Repull część po stronie gospodarza to jedna hostowana sesja z twoją marką; gospodarz wykonuje krok w Extranecie i wkleja swój Hotel ID, a ty dostajesz połączenie. Instrukcja krok po kroku jest w Łączeniu Booking.com.

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" }'

Obiekty, pokoje i plany cenowe

Zrozum to, a reszta Booking.com ułoży się sama. Pomyl to, a każdy endpoint będzie wyglądał na przypadkowy.

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

Obiekt to budynek. Pokoje to to, co rezerwują goście. Plany cenowe to warunki handlowe, na jakich sprzedaje się pokój, a cena należy do krotki (pokój, plan cenowy, data, obłożenie) – nie do nocy. Willa z jedną sypialnią to prosty przypadek; aparthotel z dwudziestoma lokalami to jeden obiekt z dwudziestoma pokojami i to norma, a nie wyjątek.

Ten sam lokal może też pojawiać się w więcej niż jednym obiekcie Booking.com, zwykle dlatego, że z czasem został wystawiony ponownie, a pokój, który nie jest przypisany do żadnej z twoich ofert, nie należy do niczego – jego rezerwacje nie mają gdzie trafić. Przypisuj pokoje podczas procesu łączenia, a nie później.

Czy mogę zmieniać stawki przez API Booking.com?

Tak, i to najczęściej używana powierzchnia całego partnerstwa. Zapisujesz cenę dla pokoju w planie cenowym na zakres dat, opcjonalnie z ograniczeniami długości pobytu i przyjazdu w tym samym wywołaniu.

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 i rateId pochodzą z GET /v1/channels/booking/properties/{id}/rooms. Cała reszta żądania – a jest jej więcej, niż się spodziewasz – jest w Aktualizacji cen w Booking.com.

Dlaczego moja zmiana ceny w Booking.com nic nie dała?

To pytanie, które przyprowadza ludzi na tę stronę, i ma dwie niezależne odpowiedzi. Obie wyglądają jak sukces.

Obłożenie jest częścią klucza, a nie preferencją

Booking.com nie przechowuje „ceny tej nocy”. Przechowuje cenę nocy dla określonej liczby osób w jednym planie cenowym. Obłożenie, które wysyłasz, decyduje więc, którą cenę nadpisujesz. Każda kwota idzie z jakimś obłożeniem, czy je podasz, czy nie.

• Podaj obłożenie powyżej maksimum wycenionego w planie, a Booking.com przyjmie żądanie i po cichu odrzuci kwotę. Noc zachowa poprzednią wartość – często 0.00 – a potwierdzenie będzie bajt w bajt identyczne jak przy udanym zapisie.
• Podaj mniejsze, a dostaniesz 400. Opublikowana cena się nie zmieni.
• Pojemność twojej własnej oferty nie jest tu właściwą liczbą. Decyduje liczba, którą Booking.com ma dla tego planu cenowego. Odczytaj ją, zamiast ją zgadywać.

Gdy nie podasz obłożenia, Repull ustala je z danych samego Booking.com dla pary (pokój, plan cenowy), zwraca użytą wartość i jej źródło, a jeśli nie da się jej ustalić, odrzuca zapis kodem 422. Kwota nigdy nie jest wysyłana w ciemno.

Pokwitowanie to nie potwierdzenie

Booking.com zwykle odpowiada na zapis stawek pustym pokwitowaniem bez statusu dla poszczególnych dat. Treść odpowiedzi to dosłownie:

{"ok": ""}

Zakresy dat i noc, którą tracisz

Pod spodem XML dostępności i stawek przyjmuje zakres, którego data to nie jest zapisywana– to granica wyłączna, tak jak data wyjazdu wyłącza ostatnią noc. Większość kalendarzy, które wcześniej integrowałeś, traktuje oba końce jako noce. Naturalnie czytasz więc „od 1 do 7 sierpnia” jako siedem nocy, a w żądaniu jest ich sześć, i noc, którą po cichu tracisz, to ostatnia noc każdego zapisywanego zakresu.

To konwersja na jedną linijkę i błąd na tydzień, bo kosztuje cię tylko ostatnią noc: kalendarz wygląda w zasadzie dobrze, wyrywkowa kontrola przechodzi, a luka wychodzi jako utracona rezerwacja, a nie błąd.

Dostępność to osobny zapis

Wycenienie nocy nie otwiera jej do sprzedaży, a otwarcie nie nadaje jej ceny. Pokoje do sprzedaży i wstrzymanie sprzedaży to osobny typ aktualizacji; wysłanie ich w aktualizacji stawek zostanie odrzucone, a nie po cichu pominięte.

# 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
    }]
  }'

Szczegóły w Wysyłaniu dostępności do Booking.com. Jeśli wolisz zapisać kalendarz raz i wysłać go do wszystkich podłączonych kanałów, służy do tego PUT /v1/availability/{propertyId}, a PATCH /v1/availability/batch dla wielu obiektów naraz.

Ograniczenia, które istnieją, i te, których nie ma

Minimalny i maksymalny pobyt (wg daty pobytu i wg daty przyjazdu), zakaz przyjazdu i zakaz wyjazdu naprawdę istnieją i można je ustawić dla pokoju, planu cenowego i zakresu dat.

Kilku ograniczeń, których ludzie się spodziewają, po prostu nie ma w powiadomieniu, które akceptuje Booking.com – m.in. dokładnej długości pobytu przy przyjeździe oraz minimalnego i maksymalnego wyprzedzenia rezerwacji. Właściwe zachowanie to ich głośne odrzucenie. Ograniczenie przyjęte, a potem niewysłane, to jedyny błąd, którego nie zobaczysz w odpowiedzi, więc Repull odpowiada 422 z nazwą pola, zamiast je pomijać. Zobacz restriction_not_supported i Minimalny pobyt i ograniczenia.

Rezerwacje, wiadomości, opinie i opłaty

• Rezerwacje – lista i potwierdzanie odbioru. Potwierdzenie to nie opcjonalna formalność: nowe rezerwacje czekają w kolejce, dopóki ich nie potwierdzisz, a partner, który nigdy nie potwierdza, w kółko odczytuje te same rezerwacje. Rezerwacje.
• Wiadomości – lista rozmów i wysyłanie. Węższe niż wątki w Airbnb; bez edycji, reakcji i statusu przeczytania. Wiadomości od gości.
• Opinie – lista i odpowiedź. Opinie.
• Opłaty i należności – odczyt i zapis. Opłaty i należności.
• Konfiguracja i uruchomienie – utworzenie podmiotu prawnego, sprawdzenie gotowości, ustawienie kontaktów i zasad oraz otwarcie obiektu do sprzedaży. Konfiguracja i uruchomienie.
• Brak zmian rezerwacji. Booking.com nie ma odpowiednika procesu zmian z Airbnb. Zmiany dat i ceny istniejącej rezerwacji nie są operacją API.

Macierz możliwości zestawia Airbnb i Booking.com obok siebie i oznacza częściowe jako częściowe, zamiast zaokrąglać w górę.

Dlaczego Content API zwraca 403?

Bo treści to osobna powierzchnia produktu z własnym uprawnieniem i własną ścieżką bazową, oddzielna od dostępności, stawek i rezerwacji. Obiekt może być w pełni aktywny – przyjmować rezerwacje i każdy zapis stawek i dostępności, który wyślesz – a każde wywołanie treści dla tego samego obiektu zwraca 403.

Gdy tak się dzieje, odruchowo podejrzewa się token, potem identyfikator obiektu, potem uprawnienia gospodarza w Extranecie. Zwykle to nic z tych rzeczy. Uprawnienie do tej powierzchni nie zostało ci przyznane, a ponowne połączenie tego nie zmieni. Sprawdź, jakie uprawnienia naprawdę obejmuje twoje partnerstwo, zanim zaplanujesz zarządzanie zdjęciami albo opisami w kolejnym wydaniu.

Treści, tam gdzie są dostępne, obejmują zdjęcia, opisy, udogodnienia, wyposażenie i zasady na poziomie obiektu lub pokoju – a Booking.com weryfikuje zmiany tekstów przed publikacją, więc zapis to początek procesu, a nie jego koniec. Treści i zdjęcia.

Co oznacza zbudowanie tego samemu

1. Status partnera i certyfikacja. Miesiące, z oceną biznesową i certyfikacją techniczną dla każdej powierzchni. Nie możesz obiecać klientowi żadnej daty.
2. Model bezpieczeństwa ze wspólnymi danymi logowania. Jedno konto maszynowe dla wszystkich obsługiwanych obiektów. Rotacja, przechowywanie i klasyfikator błędów na tyle staranny, by globalne 401 podczas awarii nie rozłączyło masowo twoich klientów.
3. Model i mapowanie. Od obiektów do pokoi, planów cenowych i twoich własnych ofert, łącznie z obiektami z wieloma pokojami, ponownie wystawionymi lokalami i nieprzypisanymi pokojami, których rezerwacje nie mają gdzie trafić.
4. Weryfikacja zapisów. Skoro pokwitowanie niczego nie dowodzi, poprawna integracja odczytuje i uzgadnia. To dodatkowe wywołanie, czas oczekiwania i maszyna stanów na twojej najgorętszej ścieżce.
5. Niezgodne konwencje. Wyłączne granice dat, ceny zależne od obłożenia, dostępność oddzielona od stawek, ograniczenia, których nie ma, XML tam, gdzie spodziewałeś się JSON.
6. Ciągłe awarie. Jak w każdym partnerskim API: to nigdy nie spada do zera.

Szczerze podsumowując: Booking.com to cięższa integracja niż Airbnb i nie dzieli prawie żadnego z jego założeń – inny model uwierzytelniania, inny model danych, inna semantyka dat, inna definicja udanego zapisu. Zespoły, które właśnie skończyły Airbnb, zawsze go nie doceniają. Przewodnik po API Airbnb to porównanie.

Gdzie pasuje Repull

Repull to jedno API REST i jeden klucz dla Booking.com, Airbnb, Vrbo, Plum Guide i systemów do zarządzania obiektami, z których gospodarze już korzystają. To my utrzymujemy relacje z partnerami; obiekty łączą się same przez hostowany proces z twoją marką.

• Jeden hostowany proces łączenia. POST /v1/connect/{provider}, z przypisywaniem pokoi w środku. Connect.
• Zapisy, które mówią prawdę. Weryfikacja przez odczyt przy stawkach, ustalone i zwracane obłożenie, nieobsługiwane ograniczenia odrzucane zamiast pomijanych, zakresy dat włączne na obu końcach.
• Jeden zapis kalendarza dla wszystkich kanałów. PUT /v1/availability/{propertyId} wysyła cenę i dostępność do każdego kanału, do którego podłączony jest obiekt.
• Webhooki z historią dostarczeń i ponownym wysłaniem zamiast osobnej infrastruktury powiadomień dla każdego kanału. Webhooki.

Zacznij od szybkiego startu albo przeczytaj przegląd kanałów. Jeśli jesteś platformą, która wbudowuje to dla własnych klientów, a nie integruje dla siebie, przewodnik dla platform omawia ten model pytanie po pytaniu.

Jeśli obiekty, które integrujesz, są już w systemie do zarządzania obiektami, to drugi, osobny problem: PMS daje ci własny obraz rezerwacji, a nie API kanału. Przewodniki po Guesty, Hostaway, Hospitable, Lodgify i OwnerRez opisują, co każdy z nich udostępnia, a macierz pokrycia zawiera je wszystkie. Jeden klucz obejmuje jednocześnie połączenie z PMS i bezpośrednie połączenie z kanałem.

Najczęstsze pytania