Límites de tasa de la API de Hyperliquid: endpoints de Info vs Exchange y cumplimiento

Respuesta directa: límites de tasa de Hyperliquid de un vistazo

Si está construyendo sobre Hyperliquid, debe tratar los endpoints /info (lectura) y /exchange (acción) como superficies con límites de tasa separados. El endpoint /info permite 200 solicitudes por segundo por IP, mientras que el endpoint /exchange permite 20 solicitudes por segundo por IP. Ambos comparten una ventana de uso de 2000 solicitudes por 5 minutos por IP, pero los límites por segundo se aplican de forma independiente. Las conexiones WebSocket tienen sus propios límites de suscripción: 1000 flujos de info y 1000 flujos de trades/L2Book por conexión. Estos límites están documentados en la documentación para desarrolladores de Hyperliquid, y se aplican tanto al acceso directo a la API como a los proveedores de RPC como los endpoints RPC de Hyperliquid de OnFinality.

La conclusión clave: si supera el límite por segundo, recibe una respuesta HTTP 429; si supera la ventana de uso, puede ser bloqueado temporalmente. Esta guía explica los mecanismos, muestra cómo verificar su uso actual y proporciona prácticas de producción para mantenerse en cumplimiento.

Comprensión de las dos familias de endpoints de Hyperliquid

La API de Hyperliquid se divide en dos familias distintas: /info y /exchange. El endpoint /info es de solo lectura y proporciona datos de mercado, estado de cuenta y datos históricos. El endpoint /exchange es para enviar órdenes, cancelaciones y otras acciones que afectan la cuenta. Cada familia tiene su propia configuración de límite de tasa y no se agrupan.

El endpoint /info está diseñado para el sondeo de alta frecuencia de datos de mercado. Admite solicitudes por lotes (hasta 20 sub-solicitudes por llamada) y es la forma principal de obtener libros de órdenes, operaciones y tasas de financiación. El endpoint /exchange es más sensible porque modifica el estado; de ahí el límite por segundo más bajo. Ambos endpoints comparten la misma ventana de uso, pero los límites por segundo se aplican por separado.

Para una inmersión más profunda en la estructura de la API, consulte los documentos de la API de Hyperliquid y la página de red de Hyperliquid de OnFinality para acceso gestionado.

Mecánica de los límites de tasa: solicitudes, ventanas de uso y encabezados

Hyperliquid aplica límites de tasa por dirección IP. Para cada solicitud, el servidor verifica dos cosas: las solicitudes por segundo (RPS) actuales y la ventana de uso móvil. La ventana de uso es una ventana deslizante de 5 minutos que cuenta todas las solicitudes a /info y /exchange combinadas. Si supera las 2000 solicitudes en esa ventana, recibirá una respuesta 429 y puede ser bloqueado por un período.

Los encabezados de respuesta incluyen x-rps-remaining, x-window-remaining y x-window-capacity para ayudarle a monitorear su uso. Por ejemplo, x-rps-remaining muestra cuántas solicitudes puede hacer aún en el segundo actual, y x-window-remaining muestra cuántas solicitudes quedan en la ventana de 5 minutos. Estos encabezados son su mejor herramienta para el cumplimiento proactivo.

Es importante tener en cuenta que el límite por segundo para /info es 200, pero si envía una solicitud por lotes con 20 sub-solicitudes, cuenta como 1 solicitud contra el límite de RPS, pero cada sub-solicitud cuenta contra la ventana de uso. Según los documentos de Hyperliquid, una solicitud por lotes cuenta como 1 solicitud contra el límite de RPS, pero cada sub-solicitud cuenta contra la ventana de uso. Los documentos dicen: 'Las solicitudes por lotes cuentan como una sola solicitud contra el límite de tasa, pero cada sub-solicitud cuenta contra la ventana de uso.' Entonces, si envía un lote de 20, consume 1 RPS y 20 créditos de ventana de uso. Este es un matiz crítico para aplicaciones de alto volumen.

• Límites por segundo: /info = 200 RPS, /exchange = 20 RPS.
• Ventana de uso: 2000 solicitudes por 5 minutos por IP, compartida entre ambos endpoints.
• Solicitudes por lotes: cuentan como 1 contra RPS, pero cada sub-solicitud cuenta contra la ventana de uso.
• Encabezados de respuesta: x-rps-remaining, x-window-remaining, x-window-capacity.

Límites de suscripción de WebSocket

Las conexiones WebSocket de Hyperliquid permiten suscribirse a flujos de datos en tiempo real. Hay dos categorías: flujos de info (por ejemplo, allMids, l2Book, trades, userFills) y flujos de trades/L2Book. El límite es de 1000 suscripciones por conexión para cada categoría. Esto significa que puede tener hasta 1000 suscripciones de info y 1000 suscripciones de trades/L2Book en una sola conexión WebSocket.

Si supera estos límites, el servidor cerrará la conexión o rechazará nuevas suscripciones. Para escalar más allá de 1000 suscripciones, necesita abrir conexiones WebSocket adicionales, pero tenga en cuenta que cada conexión también cuenta contra la tasa de solicitudes general de su IP. En realidad, las conexiones WebSocket no se cuentan contra los límites de tasa HTTP, pero tienen sus propios límites de suscripción. Para producción, es común distribuir las suscripciones en múltiples conexiones para evitar alcanzar el límite.

Para una guía práctica sobre el uso de WebSockets de Hyperliquid, consulte los documentos de WebSocket de Hyperliquid y considere usar el servicio de API de OnFinality para endpoints WebSocket gestionados.

Ejemplo ejecutable: verificación del uso de su límite de tasa

La forma más fácil de ver el estado actual de su límite de tasa es hacer una solicitud simple a /info e inspeccionar los encabezados de respuesta. A continuación se muestra un comando curl que obtiene los metadatos de la cadena Hyperliquid. Esta es una solicitud ligera que no afectará significativamente su uso.

Ejecute este comando desde su servidor o máquina local. Los encabezados de respuesta mostrarán su RPS restante y los créditos de ventana. Tenga en cuenta que los nombres exactos de los encabezados pueden variar; el ejemplo a continuación utiliza los nombres documentados.

curl -s -D - -o /dev/null https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' -d '{"type":"meta"}'

Resultados esperados y cómo verificar

Cuando ejecute el comando curl anterior, debería ver HTTP/1.1 200 OK en los encabezados de respuesta, junto con encabezados como x-rps-remaining, x-window-remaining y x-window-capacity. Por ejemplo, podría ver x-rps-remaining: 199 y x-window-remaining: 1999 si acaba de comenzar. Estos números disminuirán a medida que realice más solicitudes.

Para verificar el comportamiento del límite de tasa, puede enviar intencionalmente una ráfaga de solicitudes y observar cuándo obtiene una respuesta 429. Por ejemplo, envíe 201 solicitudes en sucesión rápida al endpoint /info y debería ver que la solicitud 201 devuelve un 429 con un mensaje como 'Rate limit exceeded'. Esta es una prueba segura porque la ventana de uso se restablece después de 5 minutos.

Recuerde que los límites exactos están documentados en la página de límites de tasa de Hyperliquid. Siempre verifique con los documentos oficiales, ya que los límites pueden cambiar.

Fallos comunes y soluciones

El fallo más común es alcanzar el límite por segundo en /exchange cuando tiene múltiples bots o procesos enviando órdenes. Esto a menudo resulta en errores 429 y operaciones perdidas. La solución es implementar un limitador de tasa en el cliente que espacie las solicitudes para mantenerse por debajo de 20 RPS.

Otro problema común es exceder la ventana de uso al sondear /info con demasiada frecuencia. Por ejemplo, si sondea cada 100 ms, hará 10 solicitudes por segundo, lo cual está bien, pero en 5 minutos eso son 3000 solicitudes, excediendo el límite de la ventana de 2000. La solución es usar suscripciones WebSocket para datos en tiempo real en lugar de sondeo, o usar solicitudes por lotes.

Un tercer problema es no contabilizar correctamente las solicitudes por lotes. Si envía un lote de 20 sub-solicitudes, cuenta como 1 RPS pero 20 créditos de ventana de uso. Si envía muchos lotes, puede agotar la ventana rápidamente. La solución es monitorear el encabezado x-window-remaining y ajustar su estrategia de lotes.

Para solución de problemas más avanzada, consulte el Asistente de RPC de OnFinality para Hyperliquid y la guía de mejores prácticas para solicitudes por lotes.

Compensaciones y limitaciones

La principal compensación es entre latencia y cumplimiento de límites de tasa. Sondear /info le da datos inmediatos pero consume créditos de ventana de uso. Los WebSockets proporcionan actualizaciones en tiempo real sin sobrecarga de solicitudes HTTP, pero requieren gestionar el estado de la conexión y la lógica de reconexión.

Otra limitación es que la ventana de uso es por IP, por lo que si tiene múltiples servidores detrás de un NAT, comparten la misma IP y, por lo tanto, el mismo límite. Esto puede ser un cuello de botella para operaciones a gran escala. La solución es usar múltiples IPs o un proveedor de RPC dedicado como OnFinality que ofrezca endpoints dedicados con límites más altos.

Además, tenga en cuenta que los límites de tasa están sujetos a cambios. Siempre consulte la documentación oficial de Hyperliquid para conocer los últimos números. Los límites mencionados en este artículo se basan en la documentación a la fecha de publicación y deben verificarse.

Prácticas de producción para mantenerse en cumplimiento

Para evitar alcanzar los límites de tasa en producción, siga estas prácticas:

Primero, almacene en caché las respuestas de meta y metaAndAssetCtxs durante al menos unos segundos, ya que cambian con poca frecuencia. Esto reduce la necesidad de sondear /info repetidamente.

Segundo, use solicitudes por lotes para combinar múltiples necesidades de datos en una sola llamada HTTP. Por ejemplo, puede obtener múltiples libros de órdenes en un solo lote. Esto reduce el número de solicitudes HTTP y ayuda a mantenerse dentro del límite de RPS.

Tercero, implemente retroceso exponencial en respuestas 429. Cuando reciba un 429, espere un tiempo corto y reintente, duplicando la espera en cada fallo posterior. Esto evita golpear la API y permite que la ventana de uso se restablezca.

Cuarto, distribuya sus suscripciones WebSocket en múltiples conexiones para mantenerse por debajo del límite de 1000 suscripciones. Por ejemplo, si necesita 1500 flujos L2Book, abra dos conexiones con 750 cada una.

Finalmente, monitoree sus encabezados de uso y configure alertas cuando se acerque a los límites. Este enfoque proactivo le ayuda a ajustar su estrategia antes de alcanzar un bloqueo.

Para una solución gestionada, considere el servicio de API de OnFinality que maneja el cumplimiento de límites de tasa y proporciona endpoints dedicados. También puede explorar la página de precios de OnFinality para planes que se adapten a su escala.

Tabla comparativa: límites de /info vs /exchange

La tabla a continuación resume los límites de tasa para las dos familias de endpoints. Los números se basan en la documentación oficial de Hyperliquid a agosto de 2026. Siempre verifique con los documentos de Hyperliquid ya que pueden cambiar.

Método: Revisamos la documentación oficial de Hyperliquid y los encabezados de respuesta de una solicitud en vivo. Suposiciones: Los límites son por dirección IP y la ventana de uso se comparte entre ambos endpoints. No realizamos pruebas de carga independientes; los números son según lo documentado.

| Endpoint | Límite por segundo | Ventana de uso (5 min) | Soporte de lotes |
|----------|------------------|----------------------|---------------|
| /info    | 200 RPS          | 2000 solicitudes        | Sí (hasta 20 sub-solicitudes) |
| /exchange| 20 RPS           | 2000 solicitudes        | No            |

Próximos pasos y lecturas adicionales

Ahora que comprende los límites de tasa de Hyperliquid, puede diseñar su aplicación para mantenerse en cumplimiento. Comience implementando las prácticas de producción descritas anteriormente y use el ejemplo de curl para monitorear su uso.

Para obtener una guía más detallada, explore el centro de aprendizaje de OnFinality para artículos sobre optimización de RPC, y consulte la página de red de Hyperliquid para endpoints gestionados. Si necesita ayuda con lotes, lea nuestra guía sobre lotes JSON-RPC.

Si está construyendo un bot de trading, considere usar el Asistente de RPC de OnFinality para obtener los mejores endpoints de baja latencia. Y para necesidades a escala empresarial, revise nuestras opciones de precios y servicio de API.