Лимиты API WEEX: где боты на самом деле получают ошибку 429

Большинство интеграций API WEEX, которые дают сбой в продакшене, не связаны с подписями. Они не работают, потому что бот воспринимает «лимит запросов» как одно число, тогда как WEEX использует два независимых бюджета — бюджет веса IP и бюджет ордеров на аккаунт, — которые обновляются в разное время и отображаются в разных заголовках ответа. Ошибетесь в этом, и вы получите HTTP 429 плюс 10-секундный бан, обычно именно в тот момент, когда из-за волатильности ваши сделки имеют решающее значение.

Это сводная карта правил лимитов API WEEX по состоянию на июль 2026 года, собранная из документации по споту и фьючерсам и сверенная с живым эндпоинтом exchangeInfo для фьючерсов. Она также охватывает то, о чем документация умалчивает: сколько запросов эти числа на самом деле вам дают.

Лимиты API WEEX вкратце

В таблице ниже объединены правила, которые в настоящее время разбросаны по четырем разным разделам документации WEEX — ограничения доступа к споту, веса эндпоинтов фьючерсов, обзор WebSocket и список ошибок в центре поддержки.

Две детали в этой таблице вызывают больше инцидентов, чем что-либо другое.

Во-первых, размещение ордеров вообще не потребляет вес IP — WEEX возвращает 0 в счетчике веса IP для этих вызовов. Во-вторых, и это ловушка, отмена и запрос ордеров по-прежнему ограничены по IP. Таким образом, маркет-мейкинговый цикл, который отменяет и перевыставляет ордера, расходует оба бюджета одновременно, и отмены — это та сторона, которая незаметно истощает пул IP.

Авторитетные числа нигде не прописаны в тексте. WEEX публикует их в массиве rateLimits, возвращаемом exchangeInfo — /capi/v3/market/exchangeInfo на https://api-contract.weex.com для фьючерсов и /api/v3/exchangeInfo для спота. Читайте этот массив при запуске вместо того, чтобы хардкодить константы.

Живые цифры и почему в документации другие данные

Вот живой ответ rateLimits для фьючерсов, полученный 27 июля 2026 года, рядом с примерами значений, напечатанными на странице документации exchangeInfo WEEX:

Это не маленькие различия — пример подразумевает около 200 веса в секунду, живой ответ разрешает около 0.83. Значения в документации — это примеры ответов, а не опубликованная квота, и любой, кто спарсил страницу документации для расчета бюджета запросов, построил систему на числе, которое ошибочно более чем на два порядка. Это самый сильный аргумент в пользу чтения exchangeInfo во время выполнения: WEEX может и меняет эти значения, и только эндпоинт говорит вам правду.

Если проработать живые цифры фьючерсов, практический потолок оказывается неудобным:

• 500 веса ÷ 600 секунд = один запрос весом 1 каждые 1.2 секунды устойчиво, на IP.
• Опрос эндпоинта весом 1 раз в секунду — стандарт для большинства учебных ботов — сжигает 600 веса за 10 минут и выводит вас за лимит до одиннадцатой минуты.
• 300 ордеров в минуту = 5 ордеров в секунду устойчиво, на аккаунт.

Бюджет ордеров щедрый. Бюджет веса IP — нет. Если ваша архитектура предполагает REST-опрос для рыночных данных, это предположение и есть то, что ломается.

Как читать заголовки лимитов WEEX

WEEX формирует имена заголовков из интервала, используя S, M, H, D для секунды, минуты, часа и дня. Таким образом, X-USED-WEIGHT-1M — это вес, потребленный вашим IP в текущем минутном окне, а X-ORDER-COUNT-10S — это ордера, размещенные вашим аккаунтом в текущем десятисекундном окне.

Парсите X-REMAINING-* в каждом ответе и регулируйте скорость на его основе. Ожидание 429, чтобы узнать, что вы были слишком быстры, — это дизайн, который гарантирует, что вы всегда будете слишком быстры, — и WEEX прямо заявляет, что после 429 вы обязаны остановиться, а не повторять запрос. Также заметьте, что путь ордеров фьючерсов сообщает как 10-секундный, так и 1-минутный счетчик ордеров, поэтому всплеск, который очищает минутный лимит, все еще может сработать на более коротком окне.

Стоит знать перед отладкой не того, что нужно: несколько ошибок выглядят как троттлинг, но ими не являются. Список кодов ошибок API WEEX отделяет 429 (превышена частота запросов) от 40008 (истек срок действия метки времени запроса — подпись действительна 30 секунд) и 40018 (недопустимый IP-запрос, что означает, что ваш вызывающий IP не в белом списке ключа). Смещение часов более чем на 30 секунд создает постоянный поток отказов, который удивительно часто ошибочно принимают за проблему лимита запросов.

Что происходит при получении 429 в API WEEX

Запрос завершается с HTTP-статусом 429, а последующие запросы зарабатывают бан на 10s. Страница ограничений доступа WEEX прямо заявляет об обязательстве: при получении 429 вы должны прекратить запросы и не злоупотреблять API.

Десять секунд звучат как терпимый срок. На практике это худшие десять секунд, которые у вас будут, потому что лимиты запросов достигаются во время волатильности — в тот самый момент, когда нужно выставить хедж или сдвинуть стоп. Правильная позиция — это токен-бакет на стороне клиента, рассчитанный по живым значениям exchangeInfo с запасом около 20%, плюс экспоненциальная задержка при любой 429, которая все же проскочила. Повторная попытка немедленно превращает 10-секундный бан в постоянный.

Создание бота, который остается в рамках лимитов API WEEX

Решение для узкого бюджета веса IP — архитектурное, а не тактическое: перестаньте опрашивать то, что может доставить поток.

WebSocket спота WEEX работает на wss://ws-spot.weex.com/v3/ws/public и wss://ws-spot.weex.com/v3/ws/private, со своими отдельными лимитами — 300 запросов на соединение на IP каждые 5 минут, максимум 100 одновременных соединений на IP, 100 каналов на соединение и 240 операций подписки в час на соединение. Это дает 10 000 слотов каналов на IP, что больше рыночных данных, чем нужно почти любой стратегии, и ничто из этого не затрагивает ваш вес REST.

Правило heartbeat здесь важно. Сервер отправляет ping и ожидает PONG; соединения, которые не отвечают более 10 раз, разрываются. Клиент, который переподключается только при закрытии сокета и никогда при пропущенных понгах, будет сидеть на мертвом потоке, пока его логика тихо торгует по старым ценам.

Практическая настройка в WEEX выглядит так:

1. Создайте ключ API в разделе Аккаунт → Управление API и привяжите белый список IP. Непривязанные ключи — самая частая причина того, что скомпрометированный аккаунт живет достаточно долго, чтобы это стало проблемой.
2. Вызывайте exchangeInfo при запуске, читайте rateLimits и рассчитывайте размер токен-бакета из ответа — никогда не используйте константу в файле конфигурации.
3. Перенесите все рыночные данные на WebSocket. Резервируйте REST для состояния аккаунта, размещения ордеров и сверки.
4. Разделите два бюджета в коде. Один ограничитель для веса IP (включая отмены и запросы), второй для количества ордеров. Один общий ограничитель либо будет без нужды троттлить ваш поток ордеров, либо превысит ваш вес.
5. Используйте эндпоинты пакетных ордеров, где позволяет стратегия. Они все еще учитываются в ORDERS, но сокращают количество запросов и задержки.
6. Сверяйтесь по таймеру, а не при каждом исполнении. Запросы позиций и баланса — это эндпоинты весом 1, которые быстро накапливаются при вызове на каждое событие.

Если вы все еще решаете, подходит ли вам подход на основе API, обзор WEEX по поддержке API-торговли охватывает решение REST против WebSocket до того, как вы примете архитектурное решение.

Что важнее всего

Из всего вышеперечисленного одно число управляет дизайном: лимит веса IP для фьючерсов в 500 за 10 минут. Он достаточно строгий, чтобы любой цикл опроса рыночных данных через REST был дисквалифицирован, что означает, что правила лимитов API WEEX — это не проблема троттлинга, которую нужно настраивать, — это сигнал о том, что платформа ожидает стриминговых клиентов. Стройте систему так с самого начала, и 429-е ошибки перестанут быть темой для обсуждения.

Сверяйте каждую цифру здесь с exchangeInfo перед запуском. Лимиты — это операционные параметры, и биржи меняют их без особого уведомления.

Часто задаваемые вопросы

1. Что такое лимит API WEEX?

WEEX применяет два лимита: бюджет REQUEST_WEIGHT на IP-адрес, покрывающий все эндпоинты, кроме размещения ордеров, и бюджет ORDERS на аккаунт, покрывающий размещение одиночных и пакетных ордеров. По состоянию на 27 июля 2026 года живой эндпоинт exchangeInfo для фьючерсов возвращает 500 веса за 10 минут и 300 ордеров в минуту. Читайте эндпоинт, а не доверяйте опубликованным цифрам, включая эту.

2. Лимит API WEEX на IP или на ключ API?

На IP для взвешенных эндпоинтов — WEEX заявляет, что эти лимиты основаны на IP, а не на ключе API или UID. Размещение ордеров — исключение: оно ограничено на аккаунт (userId). Использование нескольких ключей с одного сервера не умножает вашу квоту веса.

3. Что означает HTTP 429 в WEEX и как долго длится бан?

429 означает, что частота ваших запросов превысила лимит. WEEX применяет 10-секундный бан и ожидает, что вы прекратите отправку запросов, а не будете повторять их немедленно.

4. Учитываются ли запросы на отмену ордеров в лимите ордеров?

Нет. Только размещение одиночных и пакетных ордеров попадает под лимит ORDERS. Отмена и запрос ордеров ограничены по весу IP, поэтому стратегии с большим количеством отмен первыми исчерпывают бюджет IP.

5. Как проверить оставшуюся квоту API WEEX?

Читайте заголовки ответа. X-REMAINING-WEIGHT-1M показывает вес IP, оставшийся в текущей минуте, а X-ORDER-REMAINING-10S и X-ORDER-REMAINING-1M показывают емкость ордеров, оставшуюся для вашего аккаунта.

6. Какие лимиты WebSocket в WEEX?

300 запросов на соединение на IP каждые 5 минут, до 100 одновременных соединений на IP, максимум 100 каналов на соединение и 240 операций подписки в час на соединение. Пропустите более 10 пингов сервера, и соединение будет закрыто.

7. Почему мой запрос API WEEX не работает даже при малом объеме?

Проверьте ошибку 40008 перед тем, как предполагать троттлинг. Подписанные запросы действительны 30 секунд, поэтому часы сервера, отстающие или спешащие более чем на 30 секунд относительно времени биржи, вызывают постоянные отказы, похожие на проблему лимита запросов. Ошибка 40018 указывает на несоответствие белого списка IP.

Предупреждение о рисках

Криптоактивы волатильны, и торговля через API может привести к частичной или полной потере средств. Автоматизированные системы усугубляют этот риск: ограниченный или отключенный клиент может не успеть выставить стоп, отменить старую котировку или закрыть позицию с плечом, пока рынок движется против него, а 10-секундный бан во время скачка волатильности достаточен, чтобы превратить управляемую просадку в ликвидацию. Фьючерсные позиции несут риск плеча и могут быть ликвидированы полностью. Ключи API несут риски хранения и эксплуатации — не включенный в белый список или чрезмерно разрешенный ключ может быть использован для вывода или злоупотребления аккаунтом, поэтому ограничивайте разрешения, привязывайте белый список IP и никогда не давайте права на вывод торговому боту. Лимиты запросов, веса эндпоинтов и параметры контрактов могут быть изменены без уведомления; сверяйте их с живыми эндпоинтами перед развертыванием капитала. Ничто из этого не является инвестиционным советом.