Obsługa błędów
Nieudane odpowiedzi API zgłaszają RequiplyError:
import { RequiplyError } from '@requiply/api-sdk';
try {
await requiply.sales.create({ lines: [{ saleItemId, quantity: 1 }], paymentMethod: 'liqpay' });
} catch (error) {
if (error instanceof RequiplyError && error.reason === 'client_email_required') {
console.error('LiqPay needs a client with an email');
} else {
throw error;
}
}
Właściwości błędu
| Właściwość | Co zawiera |
|---|---|
status | Status odpowiedzi HTTP, na przykład 400, 403, 404, 409 lub 429. |
message | Czytelny dla ludzi komunikat API, a w razie jego braku opis statusu HTTP. Pokazuj go ludziom, ale nie rozgałęziaj kodu według jego treści. |
reason | Przyczyna w formie czytelnej dla programu, gdy API ją podaje, na przykład feature_disabled. Według niej rozgałęziaj kod. |
data | Dodatkowe pola wysłane przez API razem z błędem, w tym reason. |
details | Przetworzona treść odpowiedzi albo surowy tekst odpowiedzi, gdy nie jest to JSON. |
retryAfter | Liczba sekund oczekiwania z nagłówka Retry-After odpowiedzi 429. |
Przyczyny błędów
reason ustawiają zapytania o rezerwację wysyłane z kluczami publicznymi, punkty końcowe Sprzedaży oraz pozycje sprzedaży w wycenach i rezerwacjach:
reason | Status | Znaczenie |
|---|---|---|
request_only | 403 | Klucz publiczny wywołał bookings.create() bez asRequest: true. |
feature_disabled | 403 | Włącz sprzedaż jest wyłączone albo organizacja nie ma planu Advanced. |
selling_disabled | 403 | Klucz publiczny poprosił o towary na sprzedaż, a organizacja nie sprzedaje klientom. |
out_of_stock | 409 | Klucz publiczny poprosił o więcej sztuk, niż jest na półce. data.saleItemId wskazuje towar, a data.availableQuantity mówi, ile zostało. |
invalid_lines | 400 | Pozycja nie ma towaru albo jej ilość nie jest liczbą całkowitą większą od zera. |
duplicate_line | 400 | Ten sam towar występuje w dwóch pozycjach. |
sale_item_not_found | 404 | Towar nie istnieje w tej organizacji. |
sale_item_archived | 409 | Towar jest zarchiwizowany i nie można go sprzedać. |
invalid_payment | 400 | paymentMethod nie jest znaną metodą. |
payment_method_unavailable | 400 | Organizacja nie ma aktywnej integracji dla tej metody płatności. |
client_email_required | 400 | LiqPay wysyła fakturę e-mailem, więc sprzedaż wymaga klienta z adresem e-mail. |
sale_not_found | 404 | Sprzedaż nie istnieje. |
Mogą pojawić się nowe przyczyny, więc zawsze zostawiaj gałąź domyślną. Większość innych błędów, takich jak brakujące pole czy nieznana rezerwacja, zawiera tylko status i message.
Limity żądań
Każdy klucz może wykonać 100 żądań na minutę. Kolejne żądania zgłaszają RequiplyError ze status 429 i retryAfter w sekundach. W przeglądarkach retryAfter nie jest ustawiony, bo API nie udostępnia tego nagłówka między różnymi źródłami. Odczekaj kilka sekund przed ponowną próbą.
Odrzucone rezerwacje nie są błędami
bookings.create() nie zgłasza wyjątku, gdy organizacja nie może przyjąć rezerwacji, na przykład dlatego, że pozycje są zajęte w tych datach albo wydanie wypada poza godzinami pracy. Zwraca wynik success: false, message, a czasem reason. Zobacz Rezerwacje.
Błędy inne niż RequiplyError
Walidacja w konstruktorze i brakujące API środowiska uruchomieniowego zgłaszają TypeError: brakujący lub pusty apiKey, niedostępne fetch albo klucz tajny użyty w przeglądarce. Awarie sieci i przerwane żądania kończą się odrzuceniem z błędem, który zgłasza Twoja implementacja fetch.