Ліміти запитів

Ліміти рахуються на ключ, окремо для читання й запису.

Значення можуть бути вищими для вашого тарифу або окремо підняті для конкретного ключа — фактичну межу завжди видно в заголовках відповіді, покладатися варто саме на них, а не на числа з цієї таблиці.

Заголовки

Кожна відповідь містить стан поточного вікна:

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 117
X-RateLimit-Reset: 1786000860

• X-RateLimit-Limit — межа для цього типу запиту (читання або запис).
• X-RateLimit-Remaining — скільки запитів лишилось у поточній хвилині.
• X-RateLimit-Reset — час у секундах Unix, коли почнеться наступне вікно.

Вікно фіксоване: лічильник обнуляється на початку кожної хвилини, а не «ковзає».

Коли ліміт вичерпано

Перевищено хвилинний ліміт — 429 із заголовком Retry-After: 60:

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded",
    "requestId": "5f6c…"
  }
}

Вичерпано добову квоту записів — теж 429, але з іншим кодом і Retry-After до кінця доби:

{
  "error": {
    "code": "quota_exceeded",
    "message": "Daily write quota exceeded",
    "requestId": "5f6c…"
  }
}

Розрізняйте їх за code: rate_limited минеться за хвилину, quota_exceeded — лише наступної доби, і повторювати запит раніше немає сенсу.

Як правильно поводитись

• Читайте заголовки, а не ловіть помилку. Якщо X-RateLimit-Remaining наближається до нуля — пригальмуйте самі.
• Дотримуйтесь Retry-After. Це не орієнтир, а точний час до наступного вікна.
• Для повторів використовуйте експоненційну затримку з невеликим випадковим доданком, щоб паралельні процеси не поверталися одночасно.
• Не опитуйте біржу в циклі. Для «що змінилося» є параметр updatedSince (Пагінація та синхронізація), а для «з'явилося щось під мій напрямок» — вебхуки. Обидва варіанти дешевші за постійне опитування.
• Групуйте створення заявок. Один запит POST /proposals/batch до 25 позицій економить хвилинний ліміт (хоч і списує 25 одиниць добової квоти — див. Приклади).