Límites de tasa de la API de WEEX: dónde los bots realmente alcanzan el error 429

La mayoría de las integraciones de la API de WEEX que fallan en producción no fallan por las firmas. Fallan porque el bot trata el "límite de tasa" como un solo número, cuando WEEX ejecuta dos presupuestos independientes —un presupuesto de peso de IP y un presupuesto de órdenes por cuenta— que se rellenan en relojes diferentes y se reportan en diferentes encabezados de respuesta. Si te equivocas en eso, te comes un HTTP 429 más una prohibición de 10 segundos, generalmente en el momento exacto en que la volatilidad hace que tus ejecuciones importen.

Este es un mapa consolidado de las reglas de límite de tasa de la API de WEEX tal como existen en julio de 2026, extraído de la documentación de spot y futuros y verificado contra el endpoint de futuros en vivo exchangeInfo. También cubre la parte que los documentos no explican: cuánto polling te compran realmente esos números.

Límites de tasa de la API de WEEX de un vistazo

La siguiente tabla fusiona reglas que actualmente están dispersas en cuatro superficies de documentación de WEEX separadas: restricciones de acceso spot, pesos de endpoints de futuros, la descripción general de WebSocket y la lista de errores del centro de ayuda.

Dos detalles en esa tabla causan más incidentes que cualquier otra cosa.

Primero, la colocación de órdenes no consume peso de IP en absoluto — WEEX devuelve 0 en el conteo de peso de IP para esas llamadas. Segundo, y esta es la trampa, cancelar y consultar órdenes todavía están limitadas por IP. Un bucle de creación de mercado que cancela y vuelve a cotizar está, por lo tanto, gastando de ambos presupuestos a la vez, y las cancelaciones son el lado que drena silenciosamente el pool de IP.

Los números autorizados no están en prosa en ninguna parte. WEEX los publica en la matriz rateLimits devuelta por exchangeInfo — /capi/v3/market/exchangeInfo en https://api-contract.weex.com para futuros, y /api/v3/exchangeInfo para spot. Lee esa matriz al inicio en lugar de codificar constantes.

Los números en vivo, y por qué los documentos muestran otros diferentes

Aquí está la respuesta de rateLimits de futuros en vivo, obtenida el 27 de julio de 2026, junto a los valores de muestra impresos en la propia página de documentación de exchangeInfo de WEEX:

Esas no son diferencias pequeñas — la muestra implica aproximadamente 200 de peso por segundo, la respuesta en vivo permite alrededor de 0.83. Los valores de la documentación son ejemplos de respuesta de marcador de posición, no una asignación publicada, y cualquiera que haya extraído la página de documentos para dimensionar su presupuesto de solicitud ha construido contra un número que está fuera por más de dos órdenes de magnitud. Este es el argumento más fuerte para leer exchangeInfo en tiempo de ejecución: WEEX puede y cambia estos valores, y solo el endpoint te dice la verdad.

Trabaja los números de futuros en vivo y el techo práctico es incómodo:

• 500 de peso ÷ 600 segundos = una solicitud de peso-1 cada 1.2 segundos sostenida, por IP.
• Hacer polling a un endpoint de peso-1 una vez por segundo — el valor predeterminado en la mayoría de los bots de tutoriales — quema 600 de peso por 10 minutos y te pone por encima del límite antes del undécimo minuto.
• 300 órdenes por minuto = 5 órdenes por segundo sostenidas, por cuenta.

El presupuesto de órdenes es generoso. El presupuesto de peso de IP no lo es. Si tu arquitectura asume polling REST para datos de mercado, esa suposición es lo que se rompe.

Cómo leer los encabezados de límite de tasa de WEEX

WEEX construye los nombres de los encabezados a partir del intervalo, usando S, M, H, D para segundo, minuto, hora y día. Así que X-USED-WEIGHT-1M es el peso consumido por tu IP en la ventana actual de un minuto, y X-ORDER-COUNT-10S son las órdenes colocadas por tu cuenta en la ventana actual de diez segundos.

Analiza X-REMAINING-* en cada respuesta y limita la velocidad en consecuencia. Esperar a que un 429 te diga que fuiste demasiado rápido es un diseño que garantiza que serás demasiado rápido — y WEEX es explícito en que después de un 429 eres responsable de detenerte, no de reintentar. Ten en cuenta también que la ruta de órdenes de futuros reporta tanto un contador de órdenes de 10 segundos como de 1 minuto, por lo que un estallido que despeja el límite por minuto aún puede activar la ventana más corta.

Vale la pena saber antes de depurar lo incorrecto: varios errores parecen estrangulamiento pero no lo son. La lista de códigos de error de API de WEEX separa 429 (frecuencia de solicitud excedida) de 40008 (marca de tiempo de solicitud expirada — la firma es válida por 30 segundos) y 40018 (solicitud de IP ilegal, lo que significa que tu IP de llamada no está en la lista blanca de la clave). Un reloj que se desvía más de 30 segundos produce un flujo constante de rechazos que se malinterpreta sorprendentemente a menudo como un problema de límite de tasa.

Qué sucede cuando alcanzas 429 en la API de WEEX

La solicitud falla con estado HTTP 429, y las solicitudes continuas ganan una prohibición de 10s. La página de Restricciones de Acceso de WEEX establece la obligación claramente: cuando recibes un 429 debes dejar de solicitar y no debes abusar de la API.

Diez segundos suenan sobrevivibles. En la práctica son los peores diez segundos que tendrás, porque los límites de tasa se alcanzan durante la volatilidad — el mismo momento en que una cobertura necesita ser puesta o un stop necesita moverse. La postura correcta es un token bucket del lado del cliente dimensionado a partir de los valores de exchangeInfo en vivo con aproximadamente un 20% de margen, más retroceso exponencial en cualquier 429 que se escape. Reintentar inmediatamente convierte una prohibición de 10 segundos en una rodante.

Construir un bot que se mantenga bajo los límites de la API de WEEX

La solución para un presupuesto ajustado de peso de IP es arquitectónica, no táctica: deja de hacer polling para cualquier cosa que un stream pueda entregar.

El WebSocket spot de WEEX funciona en wss://ws-spot.weex.com/v3/ws/public y wss://ws-spot.weex.com/v3/ws/private, con sus propios límites separados — 300 solicitudes de conexión por IP por 5 minutos, un máximo de 100 conexiones concurrentes por IP, 100 canales por conexión y 240 operaciones de suscripción por hora por conexión. Eso suma 10,000 ranuras de canal por IP, que es más datos de mercado de los que casi cualquier estrategia necesita, y nada de eso toca tu peso REST.

La regla del heartbeat importa aquí. El servidor envía ping y espera un PONG; las conexiones que no responden más de 10 veces son terminadas. Un cliente que solo se reconecta al cierre del socket, y nunca ante pongs perdidos, se quedará en un stream muerto mientras su lógica opera silenciosamente precios obsoletos.

Una configuración práctica en WEEX se ve así:

1. Crea una clave API bajo Cuenta → Gestión de API, y vincula una lista blanca de IP. Las claves no vinculadas son la causa más común de que una cuenta comprometida sobreviva lo suficiente como para importar.
2. Llama a exchangeInfo al inicio, lee rateLimits, y dimensiona tu token bucket a partir de la respuesta — nunca a partir de una constante en tu archivo de configuración.
3. Mueve todos los datos de mercado a WebSocket. Reserva REST para el estado de la cuenta, colocación de órdenes y conciliación.
4. Separa los dos presupuestos en el código. Un limitador para el peso de IP (incluyendo cancelaciones y consultas), un segundo para el conteo de órdenes. Un solo limitador compartido estrangulará tu flujo de órdenes innecesariamente o superará tu peso.
5. Usa endpoints de órdenes por lotes donde la estrategia lo permita. Todavía cuentan contra ORDERS, pero reducen los viajes de ida y vuelta y la latencia.
6. Concilia con un temporizador, no en cada ejecución. Las consultas de posición y saldo son endpoints de peso-1 que se suman rápidamente cuando se disparan por evento.

Si todavía estás decidiendo si un enfoque basado en API encaja en absoluto, la descripción general de WEEX sobre soporte de trading API cubre la decisión REST-versus-WebSocket antes de que te comprometas con una arquitectura.

Lo que más importa

De todo lo anterior, un número gobierna el diseño: la asignación de peso de IP de futuros en vivo de 500 por 10 minutos. Es lo suficientemente restrictivo como para que cualquier bucle de mercado de datos por polling REST quede descalificado, lo que significa que las reglas de límite de tasa de la API de WEEX no son realmente un problema de estrangulamiento que deba ajustarse — son una señal de que la plataforma espera clientes de streaming. Construye de esa manera desde el principio y los 429 dejan de ser un tema.

Verifica cada cifra aquí contra exchangeInfo antes de salir a producción. Los límites son parámetros operativos, y las bolsas los cambian sin previo aviso.

FAQ

1. ¿Cuál es el límite de tasa de la API de WEEX?

WEEX aplica dos límites: un presupuesto de REQUEST_WEIGHT por dirección IP que cubre todos los endpoints excepto la colocación de órdenes, y un presupuesto de ORDERS por cuenta que cubre la colocación de órdenes simples y por lotes. A fecha de 27 de julio de 2026, el endpoint de futuros en vivo exchangeInfo devuelve 500 de peso por 10 minutos y 300 órdenes por minuto. Lee el endpoint en lugar de confiar en cualquier cifra publicada, incluida esta.

2. ¿El límite de tasa de la API de WEEX es por IP o por clave API?

Por IP para endpoints ponderados — WEEX establece que estos límites se basan en IP, no en Clave API o UID. La colocación de órdenes es la excepción: está limitada por cuenta (userId). Ejecutar varias claves desde un servidor no multiplica tu asignación de peso.

3. ¿Qué significa HTTP 429 en WEEX y cuánto dura la prohibición?

429 significa que tu frecuencia de solicitud excedió el límite. WEEX aplica una prohibición de 10 segundos y espera que dejes de enviar solicitudes en lugar de reintentar inmediatamente.

4. ¿Las solicitudes de cancelación de órdenes cuentan para el límite de tasa de órdenes?

No. Solo la colocación de órdenes simples y por lotes cae bajo el límite de ORDERS. Cancelar y consultar órdenes están limitadas por peso de IP, por lo que las estrategias con muchas cancelaciones agotan el presupuesto de IP primero.

5. ¿Cómo verifico mi cuota restante de la API de WEEX?

Lee los encabezados de respuesta. X-REMAINING-WEIGHT-1M muestra el peso de IP restante en el minuto actual, y X-ORDER-REMAINING-10S y X-ORDER-REMAINING-1M muestran la capacidad de órdenes restante para tu cuenta.

6. ¿Cuáles son los límites de WebSocket de WEEX?

300 solicitudes de conexión por IP por 5 minutos, hasta 100 conexiones concurrentes por IP, un máximo de 100 canales por conexión y 240 operaciones de suscripción por hora por conexión. Pierde más de 10 pings del servidor y la conexión se cierra.

7. ¿Por qué falla mi solicitud de API de WEEX incluso con bajo volumen?

Verifica el error 40008 antes de asumir estrangulamiento. Las solicitudes firmadas son válidas por 30 segundos, por lo que un reloj de servidor con más de 30 segundos de diferencia respecto al tiempo de la bolsa produce rechazos constantes que se asemejan a un problema de límite de tasa. El error 40018 apunta a un desajuste en la lista blanca de IP en su lugar.

Advertencia de Riesgo

Los criptoactivos son volátiles y el trading basado en API puede resultar en una pérdida parcial o total de fondos. Los sistemas automatizados agravan esa exposición: un cliente limitado o desconectado puede fallar al colocar un stop, cancelar una cotización obsoleta o cerrar una posición apalancada mientras el mercado se mueve en su contra, y una prohibición de 10 segundos durante un pico de volatilidad es suficiente para convertir una reducción manejable en una liquidación. Las posiciones de futuros conllevan riesgo de apalancamiento y pueden ser liquidadas en su totalidad. Las claves API conllevan riesgo de custodia y operativo — una clave sin lista blanca o con permisos excesivos puede ser utilizada para drenar o mal usar una cuenta, así que restringe permisos, vincula una lista blanca de IP y nunca otorgues derechos de retiro a un bot de trading. Los límites de tasa, pesos de endpoints y parámetros de contrato están sujetos a cambios sin previo aviso; verifícalos contra endpoints en vivo antes de desplegar capital. Nada aquí es asesoramiento de inversión.