La API de Hyperliquid: qué hace y cómo funciona el acceso

Dos endpoints, dos cosas muy distintas

info es público. Precios, libros de órdenes, tasas de financiamiento, metadatos de mercado, las posiciones y ejecuciones de cualquier dirección. Sin clave, sin cuenta, sin firma: los mismos datos que lee este sitio para mantener sus cifras en vivo.

exchange es donde ocurren las acciones: colocar y cancelar órdenes, transferencias, cambios de apalancamiento. Cada petición va firmada.

La separación merece interiorizarse porque explica por qué “¿hay una clave de API?” tiene una respuesta insatisfactoria. No hay clave que generar en una página de ajustes. Hay una firma, y quien firma es o su billetera o un agente que usted ha autorizado.

El modelo de billetera-agente

Esta es la parte que difiere de cualquier exchange centralizado, y es un diseño genuinamente mejor.

Usted aprueba una API wallet — un agente — que firma en nombre de su cuenta maestra o de sus subcuentas. Ese agente puede colocar y cancelar órdenes. No puede retirar.

Así que una clave de bot filtrada es un mal día, no una catástrofe. Alguien podría operar su cuenta hasta dejarla en pérdidas. No podría enviar su saldo a ninguna parte, porque sacar fondos del exchange exige la firma de la billetera maestra.

Otra nota práctica que pilla a la gente el primer día: para consultar una cuenta se pasa la dirección real de la cuenta maestra o de la subcuenta, no la del agente. Consultar con la dirección del agente devuelve datos vacíos y parece un error del sistema.

Los límites

Se aplican dos sistemas a la vez, y restringen cosas distintas.

Por IP

El peso no es uno por petición. La mayoría de las peticiones info cuestan 20, un puñado de las habituales cuestan 2, y las de exchange cuestan 1 más una fracción del tamaño del lote. Así que el presupuesto llega mucho más lejos colocando órdenes que sondeando datos, lo cual es un empujón deliberado hacia el WebSocket.

Por dirección

REST o WebSocket

WebSocket para todo lo continuo. Precios medios, actualizaciones del libro, sus propias ejecuciones. Sondear esto por REST quema peso para recibir datos que le llegarían gratis.

REST para acciones y consultas puntuales. Colocar una orden, cancelar, cambiar el apalancamiento, obtener una foto histórica una vez.

El error de principiante más común en un primer bot es sondear l2Book en un bucle. Funciona un rato, luego llega el limitador, y la solución es una suscripción, no una pausa más larga.

Lo que cuesta

Nada por usarla, y nada adicional por operar a través de ella. No hay recargo de API ni un nivel de comisiones aparte: una orden colocada por un bot paga exactamente lo que una colocada a mano, 0.045% taker o 0.015% maker en el nivel de entrada.

Eso importa para cualquier cosa que corra a menudo, porque la brecha entre maker y taker se acumula mucho más rápido en una estrategia automatizada que en la operativa manual. Dónde está el ahorro de verdad.

Antes de construir

Lea antes los tipos de orden. Post-only, reduce-only, IOC y los tipos de disparador están todos disponibles por la API, y usar el flag correcto evita categorías enteras de errores. La lista completa.

Pruebe con tamaño pequeño en la plaza real. Una testnet le dice que su código compila. No le dice cómo se comporta un libro fino contra su lógica.

Decida qué pasa cuando su proceso muera. Un bot que se detiene con órdenes en el libro las deja trabajando. Decida a conciencia si eso es lo que quiere, y considere si su estrategia necesita su propia disciplina de cancelar al desconectarse.

Asuma que el registro es público. Cada ejecución de su bot es visible para cualquiera, de inmediato, junto con sus posiciones. Cuán público es en realidad.

Dónde seguir

Empezar con el SDK de Python, que es el camino más corto de la nada a una orden colocada, y en qué pensar antes de correr un bot siquiera.