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

Обмеження частоти запитів на рівні гаманця для операцій із заявками та API-запитів.

Огляд

Обмеження частоти запитів використовує фіксовані 60-секундні вікна. Ліміти гаманця визначаються його рівнем (tier) і застосовуються до:

• Розміщення заявок (POST /order, PUT /order, WebSocket PlaceOrder і подання заявок на перпи через маршрут TEE)
• Скасування заявок (DELETE /order, DELETE /order_cloid і скасування заявок на перпи через маршрут TEE)
• API-запитів (читання в межах гаманця та інші підписані операції запису)

Окремі ліміти, прив'язані до мережевого джерела, із загальною стелею на рівні процесу, застосовуються до скасувань, авторизації агентів, записів MMP і публічних симуляцій ризику.

Лічильники зберігаються в пам'яті кожного процесу API. Вони не спільні між репліками, тому розглядайте опубліковані значення як максимум, який допустить один процес, а не як бюджет на весь кластер.

Ліміти за замовчуванням

Рівень	Заявок/хв	Скасувань/хв	API-запитів/хв	Макс. відкритих заявок	Макс. позицій
Default	60	120	600	100	50
Tier 1	30	60	300	50	20
Tier 2	120	300	1,200	500	200
Маркетмейкер	1,200	2,400	6,000	5,000	Без обмежень

Нові гаманці отримують ліміти за замовчуванням. Для підвищення рівня зверніться до служби підтримки. Ваш поточний ліміт API-запитів указано в заголовку X-RateLimit-Limit будь-якого запиту на читання в межах гаманця, наприклад GET /orders?wallet=....

Відповідь при перевищенні ліміту

Якщо ліміт перевищено, API повертає 429 Too Many Requests:

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded for OrderPlacement: 60 per minute, retry after 45 seconds",
  "retry_after_secs": 45,
  "limit": 60
}

Заголовки відповіді

Ендпоінти з лімітами на рівні гаманця повертають ці заголовки. Відповідь 429 містить X-RateLimit-Limit, X-RateLimit-Remaining: 0 і Retry-After, але не містить X-RateLimit-Reset:

Заголовок	Опис	Приклад
X-RateLimit-Limit	Максимальна кількість запитів, дозволених у вікні	60
X-RateLimit-Remaining	Кількість запитів, що залишилися в поточному вікні	42
X-RateLimit-Reset	Unix-мітка часу в секундах, коли вікно скидається (лише в успішних відповідях)	1737312060
Retry-After	Кількість секунд до повторної спроби (лише для 429)	45

Приклад заголовків відповіді

Успішний запит:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1737312060

Запит, обмежений лімітом:

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

Категорії лімітів

Ліміти відстежуються окремо для кожного типу дії:

Розміщення заявок

Враховується для кожного гаманця в межах ліміту рівня «Заявок/хв»:

• POST /order і PUT /order
• WebSocket PlaceOrder
• POST /v1/tee-perp/orders/submit та інші подання заявок на перпи, що враховуються для менеджера Account

POST /bulk_order і PUT /bulk_order обмежені 50 записами на запит.

Скасування заявок

Враховується для кожного гаманця в межах ліміту рівня «Скасувань/хв»:

• DELETE /order і DELETE /order_cloid
• Скасування заявок на перпи, що враховуються для API-гаманця, який підписує запит

Кожен маршрут скасування, зокрема DELETE /bulk_order і DELETE /bulk_order_cloid, також обмежується ще до перевірки підпису: 6,000 позицій скасування на мережеве джерело і 60,000 позицій на рівні процесу за хвилину. Пакетне скасування рахує одну позицію за кожен запис.

API-запити

Враховується для кожного гаманця в межах ліміту рівня «API-запитів/хв»:

• Читання в межах гаманця, прив'язані до параметра запиту wallet
• Підписані операції запису, не перелічені вище, наприклад конфігурація MMP і режим маржі

Подання RFQ

POST /rfq/request і команди подання RFQ через WebSocket обмежені 10 запитами на гаманець за хвилину незалежно від рівня.

Симуляція ризику

Публічні симуляції портфеля та заявок (POST /risk/simulate/portfolio, POST /risk/simulate/orders і попередній перегляд для перпів POST /v1/tee-perp/preview) мають окремі ліміти: 60 запитів на мережеве джерело і 600 запитів на рівні процесу за хвилину. Одночасно в одному процесі API може виконуватися не більше чотирьох симуляцій. Запит, який перевищує квоту або застає воркери симуляцій повністю зайнятими, отримує 429 Too Many Requests.

Авторизація агентів

POST /approve-agent, DELETE /revoke-agent і DELETE /revoke-all-agents обмежуються ще до перевірки підпису: 120 запитів на мережеве джерело і 1,200 запитів на рівні процесу за хвилину.

Записи MMP

Записи конфігурації MMP обмежуються ще до перевірки підпису: 120 запитів на мережеве джерело і 1,200 запитів на рівні процесу за хвилину, на додачу до ліміту API-запитів гаманця.

Ліміти позицій і заявок

Окрім лімітів частоти запитів, гаманці мають обмеження на максимальну кількість відкритих заявок і позицій:

Тип ліміту	Опис	Відхилення
Макс. відкритих заявок	Максимальна кількість одночасно відкритих заявок	Нова заявка відхиляється, поки гаманець перебуває на ліміті
Макс. позицій	Максимальна кількість унікальних позицій (-1 = без обмежень)	Заявка відхиляється, якщо вона відкриє нову позицію

Це відхилення заявок, а не HTTP-помилки. Відповідь на заявку має HTTP 200 зі status: "REJECTED" і reason, наприклад:

max_open_orders_exceeded: current=100, limit=100
max_positions_exceeded: wallet 0x... has 50 positions, limit is 50

Найкращі практики

Обробка лімітів

1. Відстежуйте заголовки: проактивно стежте за X-RateLimit-Remaining
2. Дотримуйтеся Retry-After: зачекайте вказаний час перед повторною спробою
3. Застосовуйте backoff: використовуйте експоненційну затримку при повторних 429

import time

def place_order_with_retry(order, max_retries=3):
    for attempt in range(max_retries):
        response = api.place_order(order)

        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            time.sleep(retry_after)
            continue

        return response

    raise RateLimitError("Max retries exceeded")

Оптимізація використання запитів

1. Використовуйте пакетні ендпоінти: POST /bulk_order для кількох заявок в одному запиті
2. Пакетні скасування: DELETE /bulk_order або DELETE /bulk_order_cloid замість кількох запитів DELETE /order
3. WebSocket для оновлень: підпишіться на оновлення заявок замість опитування GET /orders

Моніторинг

Відстежуйте ці метрики на стороні клієнта:

• Частота запитів за типом дії
• Динаміка X-RateLimit-Remaining
• Частота відповідей 429
• Середня тривалість Retry-After

Довідник помилок

HTTP-статус	Код помилки	Опис
429	rate_limit_exceeded	Ліміт перевищено, повторіть спробу через указаний час

Повний довідник помилок див. у розділі Помилки.