---
title: "Обробка помилок"
description: "Перехоплюйте збої API, розгалужуйте логіку за кодом причини та обробляйте відхилені бронювання."
canonical_url: "https://requiply.com/docs/uk/developers/typescript-sdk/error-handling"
---
# Обробка помилок

> Перехоплюйте збої API, розгалужуйте логіку за кодом причини та обробляйте відхилені бронювання.

Невдалі відповіді API викидають `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;
  }
}
```

## Властивості помилки

<table>
<thead>
  <tr>
    <th>
      Властивість
    </th>
    
    <th>
      Що містить
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        status
      </code>
    </td>
    
    <td>
      HTTP-статус відповіді, наприклад <code>
        400
      </code>
      
      , <code>
        403
      </code>
      
      , <code>
        404
      </code>
      
      , <code>
        409
      </code>
      
       або <code>
        429
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        message
      </code>
    </td>
    
    <td>
      Зрозуміле людині повідомлення API, а якщо його немає, текст HTTP-статусу. Показуйте його людям, але не будуйте логіку на його тексті.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reason
      </code>
    </td>
    
    <td>
      Машиночитна причина, коли API її надає, наприклад <code>
        feature_disabled
      </code>
      
      . Будуйте логіку саме на ній.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        data
      </code>
    </td>
    
    <td>
      Додаткові поля, які API надіслав разом із помилкою, зокрема <code>
        reason
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        details
      </code>
    </td>
    
    <td>
      Розібране тіло відповіді або сирий текст відповіді, якщо це не JSON.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        retryAfter
      </code>
    </td>
    
    <td>
      Скільки секунд чекати, із заголовка <code>
        Retry-After
      </code>
      
       відповіді <code>
        429
      </code>
      
      .
    </td>
  </tr>
</tbody>
</table>

## Причини помилок

`reason` заповнюють запити на бронювання з публічними ключами, ендпоінти [Продажі](https://requiply.com/docs/uk/developers/typescript-sdk/sales) і рядки продажу в розрахунках ціни та бронюваннях:

<table>
<thead>
  <tr>
    <th>
      <code>
        reason
      </code>
    </th>
    
    <th>
      Статус
    </th>
    
    <th>
      Значення
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        request_only
      </code>
    </td>
    
    <td>
      <code>
        403
      </code>
    </td>
    
    <td>
      Публічний ключ викликав <code>
        bookings.create()
      </code>
      
       без <code>
        asRequest: true
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        feature_disabled
      </code>
    </td>
    
    <td>
      <code>
        403
      </code>
    </td>
    
    <td>
      <strong>
        Увімкнути продажі
      </strong>
      
       вимкнено, або організація не на тарифі Advanced.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        selling_disabled
      </code>
    </td>
    
    <td>
      <code>
        403
      </code>
    </td>
    
    <td>
      Публічний ключ запросив товари на продаж, коли організація не <a href="https://requiply.com/docs/uk/developers/typescript-sdk/sales#%D0%B7-%D0%BF%D1%83%D0%B1%D0%BB%D1%96%D1%87%D0%BD%D0%B8%D0%BC-%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BC">
        продає клієнтам
      </a>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        out_of_stock
      </code>
    </td>
    
    <td>
      <code>
        409
      </code>
    </td>
    
    <td>
      Публічний ключ запросив більше одиниць, ніж є на полиці. <code>
        data.saleItemId
      </code>
      
       називає товар, <code>
        data.availableQuantity
      </code>
      
       показує, скільки залишилося.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invalid_lines
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Рядок не має товару або має кількість, яка не є цілим числом, більшим за нуль.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        duplicate_line
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Той самий товар є у двох рядках.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        sale_item_not_found
      </code>
    </td>
    
    <td>
      <code>
        404
      </code>
    </td>
    
    <td>
      Товару не існує в цій організації.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        sale_item_archived
      </code>
    </td>
    
    <td>
      <code>
        409
      </code>
    </td>
    
    <td>
      Товар архівовано, тож його не можна продати.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invalid_payment
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      <code>
        paymentMethod
      </code>
      
       не є відомим способом оплати.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        payment_method_unavailable
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Організація не має активної інтеграції для цього способу оплати.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        client_email_required
      </code>
    </td>
    
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      LiqPay надсилає рахунок електронною поштою, тому продаж потребує клієнта з email.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        sale_not_found
      </code>
    </td>
    
    <td>
      <code>
        404
      </code>
    </td>
    
    <td>
      Продажу не існує.
    </td>
  </tr>
</tbody>
</table>

Можуть зʼявлятися нові причини, тож завжди залишайте запасну гілку. Більшість інших помилок, як-от відсутнє поле чи невідоме бронювання, містять лише `status` і `message`.

## Обмеження частоти запитів

Кожен ключ може робити 100 запитів на хвилину. Наступні запити викидають `RequiplyError` зі `status` `429` і `retryAfter` у секундах. У браузерах `retryAfter` відсутній, бо API не відкриває цей заголовок для міждоменних запитів. Зачекайте кілька секунд перед повторною спробою.

## Відхилені бронювання не є помилками

`bookings.create()` не викидає помилку, коли організація не може прийняти бронювання, наприклад тому що товари на ці дати зайняті або видача припадає на неробочий час. Метод повертає `success: false` разом із `message`, а іноді й `reason`. Див. [Бронювання](https://requiply.com/docs/uk/developers/typescript-sdk/bookings#%D0%BE%D0%B1%D1%80%D0%BE%D0%B1%D0%BA%D0%B0-%D0%B2%D1%96%D0%B4%D0%BF%D0%BE%D0%B2%D1%96%D0%B4%D1%96).

## Помилки, які не є `RequiplyError`

Перевірка конструктора та відсутні API середовища викидають `TypeError`: відсутній чи порожній `apiKey`, недоступний `fetch` або секретний ключ у браузері. Мережеві збої та перервані запити завершуються помилкою, яку викидає ваша реалізація `fetch`.


## Sitemap

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