API, данные и автоматизация

Категория собирает статьи для тех, кто уже не удовлетворён интерфейсом и хочет получать данные Hyperliquid напрямую — через Info endpoint, WebSocket или Python SDK. Здесь нет вводных объяснений про то, что такое perpetual или margin: подразумевается, что вы понимаете механику HyperCore, знаете разницу между spot и perpetual контуром и представляете, зачем нужен единый account state между продуктами, включая HIP-3 рынки.

Материалы разбиты по функциональным задачам: получение метаданных и рыночного контекста, поддержание живого соединения без stale data, построение дашбордов, отправка ордеров через SDK, управление ключами через api wallets и agent wallets, архитектура ботов, работа с rate limits и, наконец, бэктестинг с учётом реальных ограничений модели данных. Это не последовательный учебник, а набор автономных инженерных решений одной и той же инфраструктурной задачи — синхронизации вашей системы с состоянием биржи.

Если вы начинаете с нуля и планируете строить систему мониторинга, логичный порядок — сначала Info endpoint для получения статичных и полустатичных данных (список рынков, метаданные контрактов, текущие параметры маржи), затем WebSocket для потоковых обновлений цен, ордербука и позиций. Это разделение принципиально: Info endpoint даёт снимок состояния, WebSocket — дельты и события в реальном времени. Ошибка в понимании этой границы приводит к дублированию логики или, наоборот, к пропущенным обновлениям.

Если ваша цель — торговый бот, а не просто монитор, маршрут другой: сначала разберитесь с моделью прав в api wallets и agent wallets, потому что архитектура авторизации определяет, как будет устроено исполнение и reconciliation. Только после этого имеет смысл переходить к статье про архитектуру бота целиком, где данные, сигнал и исполнение рассматриваются как отдельные слои с разной частотой обновления и разной толерантностью к задержкам.

Для аналитиков, которые строят dashboard по funding, open interest и объёмам, важно сначала понять источники данных и их периодичность обновления на стороне HyperCore, а уже потом проектировать слой агрегации. Здесь легко допустить архитектурную ошибку — смешать snapshot-данные из Info endpoint с потоковыми обновлениями без явной синхронизации по временным меткам.

Ни один материал в категории не заменяет проверку актуальной документации Hyperliquid по лимитам запросов, форматам полей ответа и версии API. Rate limits, коды ошибок 429 и 422, а также точные пороги для конкретных эндпоинтов — это параметры, которые меняются, и разработчик обязан сверять их с официальной спецификацией перед продакшн-деплоем, а не полагаться на цифры из статьи многомесячной давности.

То же касается структуры WebSocket-подписок и полей в ответах Info endpoint: названия каналов, вложенность объектов и семантика отдельных полей могут отличаться между версиями. Перед интеграцией стоит прогнать тестовые запросы на testnet или через публичный API и сверить реальный ответ с тем, что описано в статье, чтобы исключить расхождения из-за обновлений протокола.

Отдельного внимания требует funding rate и его расчётный период — материалы про дашборды и бэктест объясняют логику агрегации, но точный интервал начисления и формулу нужно проверять по актуальной документации, поскольку эти параметры критичны для точности PnL-расчётов и не прощают приблизительности.

Дашборд, торговый бот и бэктест — это три разных потребителя одного и того же потока данных, но с разными требованиями к задержке и полноте. Дашборд может допустить секундную задержку и работать на агрегированных данных, бот требует минимальной задержки между сигналом и исполнением, а бэктест работает с историческими fills и funding, где важна не скорость, а полнота и корректность реконструкции состояния рынка на каждый момент времени.

Именно поэтому архитектура торгового бота, описанная в соответствующем материале, разделяет слой данных, слой сигнала и слой исполнения: это позволяет переиспользовать один и тот же модуль подключения к WebSocket и для дашборда, и для бота, меняя только логику принятия решений. Reconciliation — отдельный критический элемент, потому что расхождение между ожидаемым и фактическим состоянием позиции после исполнения ордера может возникать из-за частичных fills, задержек в обработке или сетевых обрывов.

Бэктест логически замыкает цикл: он использует ту же модель данных, что и live-система, но добавляет ограничения, которых нет в реальном времени — отсутствие точного slippage, упрощённую модель funding и невозможность полностью воспроизвести микроструктуру ордербука прошлого. Материал про бэктест отдельно разбирает, какие допущения модель делает неявно и почему результаты бэктеста систематически оптимистичнее реальной торговли.

Вопрос безопасности API не выделен в отдельную категорию случайно — он пронизывает все инженерные решения, от простого дашборда до полноценного бота. Api wallets и agent wallets в Hyperliquid реализуют разделение прав: агентский кошелёк может подписывать ордера, не имея доступа к выводу средств, что принципиально меняет модель риска по сравнению с хранением приватного ключа основного аккаунта в коде бота.

Материал про права и модель ключей объясняет, как ограничить agent wallet конкретными действиями и почему ротация ключей должна быть частью операционного процесса, а не разовой настройкой. Это напрямую влияет на архитектуру бота: если исполнение и reconciliation работают через разные ключи или разные уровни доступа, схема восстановления после сбоя должна учитывать эту асимметрию прав.

Rate limits и ошибки 429/422 — не исключительная ситуация, а штатная часть работы с любым высоконагруженным API, и retry-стратегия должна быть спроектирована заранее, а не добавлена постфактум после первого падения бота в продакшне. Разница между 429 (превышение лимита) и 422 (некорректный запрос) принципиальна: первое требует экспоненциальной задержки и повторной попытки, второе — сигнал об ошибке в логике формирования запроса, повторять которую бессмысленно.

Аналогичная дисциплина нужна для WebSocket-соединений: reconnect должен сопровождаться повторной синхронизацией состояния через Info endpoint, потому что промежуток разрыва соединения — это потенциальный провал в данных, который нельзя восполнить простым переподключением к потоку. Материал про stale data разбирает конкретные признаки, по которым система должна определять, что полученные данные устарели и требуют пересинхронизации, а не продолжения работы на предположительно актуальном состоянии.