Changelog

2026-10-22

Nowe zdarzenie webhooka booking.rescheduled: rezerwacja dostała inny termin (zmienił się początek albo koniec), niezależnie od tego, kto ją przełożył. Obok data.object niesie data.previous_attributes (start, end) z terminem sprzed zmiany — w formacie full i minimal. Pozostałe zdarzenia nie mają tego klucza, ich payload się nie zmienił. Istniejące endpointy nie subskrybują nowego zdarzenia same: dopisz booking.rescheduled do events przez PATCH /v1/webhook-endpoints/{id} albo zaznacz „Przełożona” w panelu. Szczegóły: Webhooki.

2026-10-21

Zdarzenie testowe webhooka kluczem API.

Nowy endpoint POST /v1/webhook-endpoints/{id}/test (scope webhooks:manage): wysyła na endpoint podpisane zdarzenie testowe z test: true — webhook.test albo przykład wybranego typu rezerwacji (event_type, opcjonalnie booking_id) — i zwraca wynik wysyłki {ok, response_code, error}. Nic nie zapisuje w bazie. Limit: 10 wysyłek na minutę na klucz; odpowiedź może trwać do 10 s, a przy wielu testach naraz dłużej. Przykład: Testowanie integracji.
Nowe kody błędów: 422 webhook_event_not_subscribed i 422 webhook_test_booking_missing.

Warunki rezerwacji w POST /v1/bookings.

Nowy endpoint GET /v1/booking-terms (scope bookings:write): warunki rezerwacji i regulamin organizacji dla usługi i terminu (service_id, start, opcjonalnie pay_online) oraz dane administratora do klauzuli informacyjnej z art. 13 RODO (privacy_notice). Odpowiedź ma Cache-Control: no-store; podgląd niczego nie akceptuje. Dla prośby, która nie blokuje terminu, terms jest null.
POST /v1/bookings przyjmuje nowe pola terms_accepted, terms_hash i early_performance_requested.
Nowe kody błędów: 422 terms_required, 422 early_performance_required i 409 terms_changed.
Wymuszenie: w organizacji, która ma warunki do akceptacji, rezerwacja bez terms_accepted i aktualnego terms_hash jest odrzucana. Akceptacji nie wymagają organizacje bez warunków oraz prośby o rezerwację, które nie blokują terminu do czasu decyzji usługodawcy; rezerwacja czekająca na akceptację, ale blokująca termin, ją wymaga.

Koperta webhooka ma nowe pole test: false w prawdziwych dostawach, true w każdym zdarzeniu testowym wysłanym z panelu. Odbiornik nie powinien zmieniać stanu po zdarzeniu z test: true. Z panelu można też wysłać przykładowe zdarzenie wybranego typu, który endpoint subskrybuje (np. booking.payment_succeeded), zbudowane z najnowszej rezerwacji organizacji. data.object pokazuje bieżący stan tej rezerwacji, który nie musi pasować do typu (np. booking.payment_succeeded z payment.status: "not_required").

Referencja ma jeden serwer: https://api.rezeri.com. Serwer https://api.sandbox.rezeri.com został usunięty — sandbox jest zaparkowany, integrację testujesz na własnym koncie. Ścieżki, schematy i odpowiedzi się nie zmieniły.

GET /v1/availability zwraca 409 booking_unavailable, gdy organizacja nie przyjmuje rezerwacji. Wcześniej zwracało terminy, których nie dało się zarezerwować.

GET /v1/availability deklaruje w referencji odpowiedź 404 not_found (nieznana usługa albo pracownik). Zachowanie endpointu się nie zmieniło.

2026-10-19

Pierwsza publikacja referencji v1: usługi, pracownicy, dostępność, rezerwacje (odczyt, tworzenie, płatność, anulowanie) i endpointy webhooków (/v1/webhook-endpoints: lista, utworzenie, odczyt, zmiana, usunięcie; payload_format full albo minimal) ze zdarzeniami booking.created, booking.accepted, booking.cancelled, booking.payment_succeeded i booking.payment_failed.

Opisy w referencji są po polsku: grupy endpointów (Usługi, Pracownicy, Dostępność, Rezerwacje, Webhooki), podsumowania i opisy operacji, odpowiedzi i nagłówków. Ścieżki, nazwy pól i parametrów, wartości enumów, kody code i komunikaty detail się nie zmieniły.