---
title: "Obsługa błędów"
description: "Przechwytuj błędy API, rozgałęziaj kod według przyczyny i obsługuj odrzucone rezerwacje."
canonical_url: "https://requiply.com/docs/pl/developers/typescript-sdk/error-handling"
---
# Obsługa błędów

> Przechwytuj błędy API, rozgałęziaj kod według przyczyny i obsługuj odrzucone rezerwacje.

Nieudane odpowiedzi API zgłaszają `RequiplyError`:

```ts
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

<table>
<thead>
  <tr>
    <th>
      Właściwość
    </th>
    
    <th>
      Co zawiera
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        status
      </code>
    </td>
    
    <td>
      Status odpowiedzi HTTP, na przykład <code>
        400
      </code>
      
      , <code>
        403
      </code>
      
      , <code>
        404
      </code>
      
      , <code>
        409
      </code>
      
       lub <code>
        429
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        message
      </code>
    </td>
    
    <td>
      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.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reason
      </code>
    </td>
    
    <td>
      Przyczyna w formie czytelnej dla programu, gdy API ją podaje, na przykład <code>
        feature_disabled
      </code>
      
      . Według niej rozgałęziaj kod.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        data
      </code>
    </td>
    
    <td>
      Dodatkowe pola wysłane przez API razem z błędem, w tym <code>
        reason
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        details
      </code>
    </td>
    
    <td>
      Przetworzona treść odpowiedzi albo surowy tekst odpowiedzi, gdy nie jest to JSON.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        retryAfter
      </code>
    </td>
    
    <td>
      Liczba sekund oczekiwania z nagłówka <code>
        Retry-After
      </code>
      
       odpowiedzi <code>
        429
      </code>
      
      .
    </td>
  </tr>
</tbody>
</table>

## Przyczyny błędów

`reason` ustawiają zapytania o rezerwację wysyłane z kluczami publicznymi, punkty końcowe [Sprzedaży](https://requiply.com/docs/pl/developers/typescript-sdk/sales) oraz pozycje sprzedaży w wycenach i rezerwacjach:

<table>
<thead>
  <tr>
    <th>
      <code>
        reason
      </code>
    </th>
    
    <th>
      Status
    </th>
    
    <th>
      Znaczenie
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        request_only
      </code>
    </td>
    
    <td>
      <code>
        403
      </code>
    </td>
    
    <td>
      Klucz publiczny wywołał <code>
        bookings.create()
      </code>
      
       bez <code>
        asRequest: true
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        feature_disabled
      </code>
    </td>
    
    <td>
      <code>
        403
      </code>
    </td>
    
    <td>
      <strong>
        Włącz sprzedaż
      </strong>
      
       jest wyłączone albo organizacja nie ma planu Advanced.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        selling_disabled
      </code>
    </td>
    
    <td>
      <code>
        403
      </code>
    </td>
    
    <td>
      Klucz publiczny poprosił o towary na sprzedaż, a organizacja nie <a href="https://requiply.com/docs/pl/developers/typescript-sdk/sales#z-kluczem-publicznym">
        sprzedaje klientom
      </a>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        out_of_stock
      </code>
    </td>
    
    <td>
      <code>
        409
      </code>
    </td>
    
    <td>
      Klucz publiczny poprosił o więcej sztuk, niż jest na półce. <code>
        data.saleItemId
      </code>
      
       wskazuje towar, a <code>
        data.availableQuantity
      </code>
      
       mówi, ile zostało.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invalid_lines
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Pozycja nie ma towaru albo jej ilość nie jest liczbą całkowitą większą od zera.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        duplicate_line
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Ten sam towar występuje w dwóch pozycjach.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        sale_item_not_found
      </code>
    </td>
    
    <td>
      <code>
        404
      </code>
    </td>
    
    <td>
      Towar nie istnieje w tej organizacji.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        sale_item_archived
      </code>
    </td>
    
    <td>
      <code>
        409
      </code>
    </td>
    
    <td>
      Towar jest zarchiwizowany i nie można go sprzedać.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invalid_payment
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      <code>
        paymentMethod
      </code>
      
       nie jest znaną metodą.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        payment_method_unavailable
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Organizacja nie ma aktywnej integracji dla tej metody płatności.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        client_email_required
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      LiqPay wysyła fakturę e-mailem, więc sprzedaż wymaga klienta z adresem e-mail.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        sale_not_found
      </code>
    </td>
    
    <td>
      <code>
        404
      </code>
    </td>
    
    <td>
      Sprzedaż nie istnieje.
    </td>
  </tr>
</tbody>
</table>

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](https://requiply.com/docs/pl/developers/typescript-sdk/bookings#obs%C5%82uga-odpowiedzi).

## 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`.


## Sitemap

See the full [sitemap](https://requiply.com/docs/sitemap.md) for all pages.