Limity

API ogranicza liczbę żądań, żeby jedna integracja nie zablokowała pozostałych. Limity liczymy osobno dla każdego klucza API, w oknach minutowych.

Limity na klucz API

Zakres	Limit
Każde uwierzytelnione żądanie	120 na minutę
POST /v1/bookings — tworzenie rezerwacji	dodatkowo 20 na minutę
POST /v1/bookings/{booking_id}/payment — sesja płatności	dodatkowo 20 na minutę

Limity tworzenia rezerwacji i sesji płatności to osobne liczniki. Żądanie na tych trasach zużywa budżet ogólny (120/min) i budżet trasy (20/min).

Powtórka z tym samym Idempotency-Key też zużywa budżet — licznik działa przed idempotencją. Żądanie odrzucone na walidacji body (422) albo przez brak scope (403) nie zużywa budżetu trasy, tylko ogólny.

Nagłówki

Każda odpowiedź na uwierzytelnione żądanie — także z błędem — niesie:

Nagłówek	Znaczenie
X-RateLimit-Limit	Limit w bieżącym oknie.
X-RateLimit-Remaining	Ile żądań zostało w bieżącym oknie.
X-RateLimit-Reset	Koniec bieżącego okna jako czas Unix w sekundach.

Na trasach tworzenia rezerwacji i sesji płatności nagłówki opisują okno 20/min. Wyjątek: odpowiedzi 422 i 403 sprzed licznika trasy opisują okno ogólne 120/min. Odpowiedź 500 internal_error nie ma tych nagłówków, choć żądanie zużyło budżet.

Przekroczenie limitu

Po przekroczeniu limitu dostajesz 429 rate_limited z nagłówkiem Retry-After — liczbą sekund do końca okna (co najmniej 1).

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
X-RateLimit-Limit: 20
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1792411440
Retry-After: 28

Nieudane uwierzytelnienie

Żądanie bez klucza albo z kluczem odrzuconym (401) zużywa budżet nieudanych uwierzytelnień adresu IP: 30 na minutę. Udane uwierzytelnienie go nie zużywa.

Po wyczerpaniu tego budżetu każde żądanie z tego adresu IP dostaje 429 rate_limited z Retry-After — także z poprawnym kluczem — do końca okna. Inne adresy IP działają dalej. Ta odpowiedź i odpowiedzi 401 nie mają nagłówków X-RateLimit-*.

Nie ponawiaj 401 w pętli. Popraw klucz i dopiero wtedy wyślij żądanie.

Limit rezerwacji klienta

Niezależnie od limitów klucza tworzenie rezerwacji chroni przed zalewaniem klientów i usługodawców powiadomieniami. Gdy limit zadziała, dostajesz 429 client_booking_limit z Retry-After: 3600. To inny kod niż rate_limited: dotyczy danych w żądaniu, nie tempa Twojego klucza.

Limit działa, gdy:

• ten sam adres e-mail albo numer telefonu klienta przekroczy 5 rezerwacji na godzinę albo 20 na dobę — liczone łącznie w całym Rezeri, także z widżetu,
• pracownik ma już 200 oczekujących przyszłych rezerwacji.

Ponowienie tego samego żądania od razu nie pomoże. Pokaż użytkownikowi błąd albo spróbuj po czasie z Retry-After.

Jak ponawiać

• Po 429 odczekaj liczbę sekund z Retry-After. Nie ponawiaj wcześniej.
• Śledź X-RateLimit-Remaining i zwolnij, zanim dojdziesz do zera. Zadania wsadowe rozłóż w czasie.
• Przy 5xx, 409 idempotency_in_progress i błędach sieci ponawiaj z wykładniczym odstępem i losowym rozrzutem (np. 1 s, 2 s, 4 s… plus losowe opóźnienie), z limitem prób.
• Inne błędy 4xx nie znikną po ponowieniu. Popraw żądanie.
• Ponawiając POST, wysyłaj ten sam Idempotency-Key — patrz Idempotencja.