Przejdź do głównej treści
API GetQR jest w wersji beta i jest dostępne dla wybranych obszarów roboczych. Szczegóły mogą się zmienić przed ogólną premierą.
API GetQR używa standardowych kodów statusu HTTP. Udane żądania zwracają 2xx. Nieudane żądania zwracają 4xx lub 5xx z treścią JSON, która wyjaśnia, co poszło nie tak.

Format błędu

Każdy błąd ma ten sam kształt: stały kod, czytelny komunikat i link do opisu tego kodu.
string
wymagane
Stały, czytelny maszynowo kod błędu. Używaj go w swoim kodzie zamiast komunikatu. Zobacz Kody błędów.
string
wymagane
Czytelny dla człowieka opis problemu. Jego treść może się zmienić.
string
wymagane
Link do opisu kodu błędu w dokumentacji API na Twoim koncie GetQR.

Kody błędów

Błędy walidacji

Gdy treść lub parametry zapytania nie przejdą walidacji, API odpowiada 422. Komunikat opisuje pierwsze nieprawidłowe pole w postaci <issue>: <field>: <details>:
Pola zagnieżdżone są zapisywane w notacji kropkowej, np. link.url.

Obsługa błędów

  • Rozgałęziaj logikę według error.code, a nie error.message.
  • Nie ponawiaj błędów 4xx bez zmian: najpierw popraw żądanie. Wyjątkami są 409 dla żądania, które wciąż trwa, oraz 429.
  • Przy 429 odczekaj liczbę sekund podaną w nagłówku Retry-After. Zobacz Limity żądań.
  • Ponawiaj błędy 5xx z wykładniczym wydłużaniem odstępów.

Typowe problemy

API jest w wersji beta i nie zostało jeszcze włączone dla Twojego obszaru roboczego.
Ścieżka jest nieprawidłowa. Porównaj ją ze stronami endpointów i sprawdź, czy zaczyna się od /api/v1/.
Subskrypcja właściciela obszaru roboczego wygasła. Klucz API zacznie znowu działać, gdy tylko właściciel odnowi subskrypcję.
Masz w obszarze roboczym rolę przeglądającego. Z API mogą korzystać tylko właściciel obszaru roboczego i edytorzy.

Co dalej

Limity żądań

Uwierzytelnianie