Skip to main content
Każda odpowiedź z błędem /v1 ma format application/problem+json (RFC 9457) i zawiera stały zestaw pól:
Logikę rozgałęziania należy opierać na code, nigdy na detail — code jest stabilnym kontraktem maszynowym, a detail jest czytelne dla człowieka i może ulec zmianie. Pole param występuje wtedy, gdy błąd można przypisać do konkretnego parametru żądania. Podczas kontaktu z pomocą techniczną należy podać request_id.

Kody błędów

Zbiór kodów jest zamknięty: nowe kody oznaczają zmianę publicznego kontraktu i są ogłaszane w dzienniku zmian API. Odpowiedź retryable: true oznacza, że przyczyna błędu może ustąpić, ale nie dowodzi, że operacja zapisu nie wywołała żadnego skutku. Operacje odczytu należy ponawiać w ramach skończonej liczby prób i ograniczonego czasu, stosując wykładniczy backoff z jitterem. Jeśli nagłówek Retry-After występuje, należy go uwzględnić, także w przypadku ponawialnego błędu 409 lub 429. W przypadku operacji modyfikujących należy postępować zgodnie z udokumentowanym dla danej operacji kontraktem idempotentności i odzyskiwania. Jeśli jest to obsługiwane, należy zachować pierwotny klucz i pierwotne żądanie. Po przekroczeniu limitu czasu lub wystąpieniu błędu 5xx nie należy tworzyć nowego klucza: może to spowodować powtórzenie zapisu, który zakończył się powodzeniem. Nagłówek Idempotency-Key nie zapewnia żadnej ochrony w przypadku operacji, która go nie obsługuje.