Przejdź do głównej zawartości
Polski

API dla programistów

Po coDać programiście hotelu albo integratorowi punkt startowy: co to za API, gdzie jest jego specyfikacja i jak wygląda dostęp.
Dla kogoProgramiście, który podłącza do HotelsCalendar własny system; właścicielowi — żeby przekazać zadanie wykonawcy.
Co uzyskaszObraz powierzchni API — jakie dane można przez nie pobrać — oraz zrozumienie procesu dostępu: token i bazowy adres URL.
OgraniczeniaTo punkt startowy, a nie spis metod: pełne zestawienie żyje w specyfikacji, a limity techniczne nie są publikowane.

HotelsCalendar ma API: te same rezerwacje, dostępność i goście, z którymi pracujesz w interfejsie — programowo. Ta strona jest punktem startowym: co to za interfejs, gdzie jest jego specyfikacja i jak uzyskać dostęp. Przykładów z kodem tu nie ma — zastępuje je specyfikacja.

API to programowy interfejs ponad produktem. Oddaje i przyjmuje te same dane, co interfejs PMS: rezerwacje, dostępność, gości. Interfejs jest dla ludzi, API — dla programów: własny system księgowy, skrypt albo arkusz czyta i zmienia dane obiektu bez ręcznego przenoszenia.

Dane w API mówią tym samym językiem, co artykuły tej dokumentacji: rezerwacje ze statusami i gośćmi, dostępność w podziale na dni, dane gości. Dlatego przed podłączeniem warto zrozumieć, jak produkt opisuje te pojęcia — od tego zaczyna się każda integracja.

Pełny opis API to specyfikacja OpenAPI, plik openapi.yaml: wymienia wszystkie metody — co każda przyjmuje i zwraca — oraz modele danych. Specyfikacja jest pogrupowana w około 24 sekcje tematyczne.

Specyfikację otwiera się i pobiera pod bazowym adresem URL API — adresem, który dostajesz wraz z dostępem. To źródło prawdy o możliwościach: wszystko, co opisuje, API potrafi; czego w niej nie ma, tego API nie obiecuje.

Dostęp do API działa na tokenie: osobistym kluczu, który przekazywany jest z każdym żądaniem. Po tokenie API wie, z jakiego obiektu pochodzi żądanie i co wolno temu dostępowi.

Token i bazowy adres URL przychodzą razem — przy podłączaniu (jak o niego poprosić — niżej). Traktuj token jak hasło: otwiera dane obiektu, więc przechowujesz go po swojej stronie i nie publikujesz.

  • Własna analityka. Rezerwacje trafiają do Twojego systemu BI albo arkusza — i liczą się tam tak, jak potrzebujesz, bez ręcznego eksportu co miesiąc.
  • Synchronizacja z systemami wewnętrznymi. Program księgowy albo serwis obiektu otrzymuje rezerwacje i zmiany z PMS — dane nie rozchodzą się między systemami.
  • Drobne serwisy i widgety. Lekkie narzędzie oparte na danych obiektu — wewnętrzna strona dla personelu, podsumowanie dla zarządzającego — które czyta dane z PMS bezpośrednio.

We wszystkich trzech scenariuszach droga jest ta sama: uzyskaj token, znajdź potrzebne metody w specyfikacji, podłącz swój system.

  • Limity techniczne API — częstotliwość żądań, rozmiary eksportów — nie są publikowane w tym artykule.
  • Wykaz możliwości to wyłącznie specyfikacja: metody i modele opisuje openapi.yaml, artykuł niczego ponad nią nie obiecuje.
  • Jak API zmienia się w czasie — zgodność wersji, sposób powiadamiania o zmianach — o tym ta strona też niczego nie obiecuje: warunki ustalane są przy podłączaniu.
  • Przykładów krok po kroku z kodem tu też nie ma — ich rolę pełni specyfikacja.
  1. Napisz do nas przez stronę „Kontakt” witryny HotelsCalendar: opisz zadanie — jaki system podłączasz i jakie dane są mu potrzebne.
  2. Prześlemy token i bazowy adres URL API.
  3. Dalej — według specyfikacji: znajdź metody pod swoje zadanie i podłącz swój system.

Jeśli pytanie dotyczy nie programowania, a konfiguracji obiektu — zacznij od strony wsparcia.

  • Wsparcie i kontakt — gdzie i jak pisać do zespołu: od wsparcia zaczyna się też dostęp do API.
  • Słownik terminów hotelowych — wyjaśnienie terminów hotelowych, które pojawią się w danych: rezerwacja, dostępność, stawka, zameldowanie.