API de exchanges cripto para arbitraje: REST vs WebSocket, límites de solicitudes y claves API seguras 01/10/2026 – Publicado en: Arbitrage Software, cryptoarbitrage software
Cómo conectarse a las API de exchanges cripto para arbitraje: REST, WebSocket, límites de solicitudes y latencia
Una oportunidad de arbitraje solo existe mientras tu bot pueda verla y actuar sobre ella, y ambas cosas dependen de cómo te conectas a cada exchange. Esta guía explica las decisiones que determinan si una diferencia de precio se convierte en una orden ejecutada o en una operación perdida: qué tipo de API usar, cómo funcionan los límites de solicitudes en Binance, Bybit, OKX, MEXC y Gate.io, cómo crear claves API seguras y en qué se van los milisegundos.
- Por qué la conexión API decide los resultados del arbitraje
- REST vs WebSocket: para qué sirve cada uno
- Límites de solicitudes en los principales exchanges
- Cómo crear claves API de forma segura
- De dónde viene la latencia y cómo reducirla
- Cómo mantener una conexión fiable
- Lista de verificación antes del lanzamiento
- Preguntas frecuentes
Por qué la conexión API decide los resultados del arbitraje
El arbitraje entre exchanges parece sencillo sobre el papel: compras donde el precio es más bajo, vendes donde es más alto y te quedas con la diferencia menos las comisiones. En la práctica, esa diferencia suele durar desde unos cientos de milisegundos hasta unos pocos minutos, y toda la operación pasa por las API de los exchanges. Tres factores técnicos determinan cuánto capturas realmente:
- Qué tan rápido ves el precio. Si tus cotizaciones llegan tarde, la diferencia que calculas puede haber desaparecido ya.
- Qué tan rápido llegan tus órdenes. Hay que ejecutar dos patas en dos plataformas; la pata más lenta fija tu precio de entrada real.
- Con qué frecuencia se te permite consultar. Los límites de solicitudes restringen el número de peticiones. Un bot que los alcanza queda bloqueado justo cuando el mercado está más activo y las diferencias son más amplias.
Nada de esto se ve en un backtest, y por eso dos bots con la misma estrategia pueden dar resultados muy distintos. Si todavía no has medido las diferencias entre tus exchanges, empieza con nuestro escáner de arbitraje cripto gratuito: muestra qué pares y plataformas generan diferencias de precio lo bastante grandes para cubrir las comisiones.
REST vs WebSocket: para qué sirve cada uno
Todos los grandes exchanges ofrecen dos formas de comunicarse con ellos.
REST API funciona por solicitud y respuesta. El bot envía una solicitud HTTP firmada (por ejemplo, «dame el libro de órdenes» o «coloca esta orden») y espera la respuesta. Cada solicitud es independiente, fácil de depurar y cuenta para el límite de solicitudes.
WebSocket API mantiene una única conexión abierta. Después de suscribirte a un canal, el exchange te envía cada actualización (cambios en el libro de órdenes, operaciones, el estado de tus propias órdenes) en el momento en que ocurre. No hay sondeo ni intervalos ciegos entre consultas.
| REST | WebSocket | |
|---|---|---|
| Datos de mercado | Instantánea bajo petición; los cambios entre consultas se pierden | Flujo continuo de actualizaciones del libro de órdenes y de operaciones |
| Uso típico en arbitraje | Arbitraje hedge (entre exchanges) con diferencias que duran segundos o más; saldos; retiros | Arbitraje de latencia y cualquier estrategia con diferencias que duran menos de un segundo |
| Presión sobre los límites | Alta: cada consulta de precio consume peso | Baja para datos: una suscripción en lugar de miles de solicitudes |
| Complejidad | Baja | Mayor: reconexiones, números de secuencia, mantenimiento del libro de órdenes local |
La mayoría de las configuraciones profesionales combinan ambos: WebSocket para datos de mercado y actualizaciones de órdenes, REST (o el endpoint de trading por WebSocket del exchange, si existe) para colocar órdenes, y REST para llamadas administrativas lentas como saldos y transferencias.
Esta es también la diferencia práctica entre nuestros dos bots cripto. VIP Crypto Arbitrage se conecta por REST a más de 35 exchanges y está diseñado para el arbitraje hedge entre exchanges, donde las diferencias persisten el tiempo suficiente. SharpTrader Pro utiliza feeds WebSocket de más de 40 exchanges, algo imprescindible para el arbitraje de latencia, donde la ventana es de 100–500 ms.
Límites de solicitudes en los principales exchanges
Los límites de solicitudes son la causa más común de que los bots de arbitraje dejen de funcionar en trading real. Cada exchange cuenta tus solicitudes por dirección IP, por cuenta (UID) o por clave API, y te bloquea o te veta cuando superas el presupuesto. La tabla siguiente resume las reglas publicadas en el momento de escribir este artículo (septiembre de 2026). Los límites cambian con frecuencia, así que consulta siempre la documentación del exchange y lee las cabeceras de límites en las respuestas reales.
| Exchange | Principales límites REST | Qué ocurre al superarlos | Detalles útiles |
|---|---|---|---|
| Binance (Spot) | Peso de solicitudes de 6,000 por minuto por IP; límites aparte para el número de órdenes. Cada endpoint tiene su propio peso | HTTP 429; seguir enviando tras un 429 provoca HTTP 418 y un bloqueo automático de la IP de 2 minutos hasta 3 días para los reincidentes | Las cabeceras X-MBX-USED-WEIGHT-* y X-MBX-ORDER-COUNT-* muestran el uso actual; Retry-After indica cuánto esperar |
| Bybit (V5) | 600 solicitudes cada 5 segundos por IP; límites por UID para trading, p. ej. crear orden 20/s en spot y 10/s en contratos lineales | Límite por IP: HTTP 403 «access too frequent», que se levanta tras unos 10 minutos; límite por UID: retCode 10006 | Cabeceras X-Bapi-Limit, X-Bapi-Limit-Status, X-Bapi-Limit-Reset-Timestamp |
| OKX (V5) | Los límites se fijan por endpoint y por instrumento, y los niveles VIP más altos obtienen más capacidad | Respuesta de error del endpoint; el abuso repetido puede restringir la clave | Canales del libro de órdenes: bbo-tbt (mejor bid/ask, cada 10 ms), books5 (cada 100 ms), books (incremental, 100 ms); los canales L2 tick a tick requieren niveles VIP más altos |
| MEXC (Spot v3) | Los endpoints con peso por IP comparten 300 de peso cada 10 segundos; los endpoints con peso por UID, 500 cada 10 segundos | HTTP 429 con Retry-After; las infracciones repetidas provocan bloqueos de IP de 2 minutos a 3 días |
WebSocket: hasta 30 streams por conexión, 100 mensajes por segundo; la conexión se cierra tras 60 s sin tráfico (responde a los pings) |
| Gate.io (API v4) | Límites publicados por clave para endpoints spot públicos y privados, con un límite mucho más alto para la cancelación de órdenes | Las solicitudes cercanas al umbral de ráfaga se retrasan; las que lo superan se rechazan | WebSocket: hasta 300 conexiones por IP |
Tres reglas mantienen un bot dentro de los límites:
- Obtén los datos de mercado por WebSocket, no por REST. Un bot que consulta el libro de órdenes de 20 pares en 5 exchanges cada 200 ms envía 500 solicitudes por segundo. Los mismos datos por WebSocket cuestan solo unas pocas suscripciones.
- Lee las cabeceras de límites y reduce el ritmo antes de que el exchange lo haga por ti. Un bot que frena al 80% del presupuesto nunca sufre un bloqueo.
- Separa el tráfico. Usa claves API distintas (o subcuentas) para cada bot, de modo que un script descontrolado no pueda bloquear tu clave de trading.
Cómo crear claves API de forma segura
Un bot de arbitraje necesita permiso para leer saldos y colocar órdenes. Nunca necesita permiso para retirar fondos. Una clave filtrada sin derechos de retiro puede causar pérdidas mediante malas operaciones, pero no puede vaciar la cuenta.
- Crea una clave por exchange y por bot, y nómbrala según el bot y el servidor.
- Activa solo lectura y trading spot/futuros. Mantén los retiros desactivados.
- Restringe la clave a la dirección IP de tu VPS. La mayoría de los exchanges admiten una lista blanca de IP; una clave limitada a una sola IP no sirve en ninguna otra máquina.
- Guarda los secretos cifrados en el servidor, nunca en capturas de pantalla, chats ni documentos compartidos.
- Rota las claves tras cualquier cambio de personal, migración de servidor o sospecha de filtración, y elimina las claves que ya no uses.
- Para estrategias separadas, usa subcuentas: aíslan los saldos y los límites de solicitudes.
De dónde viene la latencia y cómo reducirla
Desde el momento en que el precio cambia en el exchange hasta que tu orden se ejecuta, el tiempo se reparte en cinco puntos: la actualización de mercado viaja hasta tu servidor, tu bot detecta la diferencia, la orden firmada viaja de vuelta, el exchange la casa y la confirmación regresa. En un bot bien escrito, el procesamiento lleva unos pocos milisegundos. Lo que suele dominar es la red.
- Aloja el bot cerca del exchange. La mayoría de los grandes exchanges ejecutan sus motores de emparejamiento en regiones de nube concretas (muchos en Tokio, Singapur o Hong Kong). Un VPS en la misma región puede reducir el tiempo de ida y vuelta de decenas de milisegundos a unos pocos. Nuestra guía de velocidad de VPS explica cómo medirlo.
- En estrategias con varios exchanges, elige la ubicación que minimice la pata más lenta, no la media: la operación solo es tan rápida como su ejecución más lenta.
- Mantén las conexiones activas. Reutiliza las conexiones HTTPS (keep-alive) y prefirma lo que puedas; abrir una nueva conexión TLS por cada orden añade un viaje de ida y vuelta completo.
- Mide de forma continua. Registra la marca de tiempo del exchange de cada actualización frente a tu reloj local (sincronizado con NTP) y controla la antigüedad de las cotizaciones con las que opera tu bot.
Cómo mantener una conexión fiable
Las conexiones WebSocket se caen. Los exchanges cierran flujos inactivos, reinician servidores y limitan la duración de las conexiones. Un bot robusto lo tiene previsto:
- Heartbeats: responde a los pings (MEXC cierra una conexión tras 60 segundos sin tráfico) y envía los tuyos si el exchange lo exige.
- Comprobación de secuencia: los flujos incrementales del libro de órdenes incluyen identificadores de actualización. Si falta uno, descarta el libro local y vuelve a sincronizar desde una instantánea nueva en lugar de operar con un libro corrupto.
- Reconexión automática con espera progresiva: reconecta rápido, pero no en un bucle cerrado; Bybit, por ejemplo, limita las nuevas conexiones por ventana de 5 minutos.
- Protección contra datos obsoletos: si no llega ninguna actualización de un par en un tiempo determinado, deja de operar ese par hasta que el flujo se recupere.
- Conciliación del estado de las órdenes: tras una reconexión, consulta por REST las órdenes abiertas y las posiciones antes de colocar nada nuevo, para que nunca se olvide un hedge ejecutado a medias.
- Sigue los avisos de cambios en las API. Los exchanges retiran endpoints y cambian límites varias veces al año. Nuestro rastreador de cambios en las API de exchanges cripto reúne estos anuncios en un solo lugar.
Lista de verificación antes del lanzamiento
- Diferencias de precio confirmadas en tus pares con el escáner, después de comisiones.
- Una clave API por exchange: solo trading, retiros desactivados, lista blanca de IP configurada.
- Datos de mercado por WebSocket; llamadas REST limitadas a órdenes y datos de la cuenta.
- Cabeceras de límites registradas; el bot frena antes del 80% del presupuesto.
- VPS en la región que minimiza la pata más lenta; tiempos de ida y vuelta medidos.
- Protecciones de reconexión, resincronización y datos obsoletos probadas cortando la red a propósito.
- Primera ejecución real con el tamaño mínimo y, después, comparación de las ejecuciones con los precios que vio el bot.
Deja que el software se ocupe de la infraestructura
La gestión de conexiones, la firma de solicitudes, los límites y las reconexiones ya vienen integrados en nuestros bots. Empieza con el escáner gratuito y luego elige el bot que se ajuste a tu estrategia.
Escáner de arbitraje cripto gratuito Comparar bots de arbitraje cripto
Preguntas frecuentes
¿Necesito WebSocket para el arbitraje cripto?
Para el arbitraje de latencia, sí: la oportunidad dura menos de un segundo y el sondeo no puede verla a tiempo. Para el arbitraje hedge (entre exchanges), donde las diferencias persisten durante segundos o minutos, REST es suficiente, aunque WebSocket sigue reduciendo el consumo de los límites de solicitudes.
¿Por qué mi bot recibe errores HTTP 429 o 418 en Binance?
429 significa que superaste un límite de solicitudes; 418 significa que la IP fue bloqueada porque las solicitudes continuaron después del 429. Pasa los datos de mercado a WebSocket, respeta la cabecera Retry-After y reduce el ritmo antes de alcanzar el límite.
¿Debe una clave API de arbitraje permitir retiros?
No. Con trading y lectura es suficiente. El reequilibrio entre exchanges puede hacerse manualmente o mediante un proceso separado y estrictamente restringido.
¿Qué ubicación de servidor es mejor para el arbitraje entre varios exchanges?
La que minimiza la pata más lenta de tu operación. Mide los tiempos de ida y vuelta desde las regiones candidatas hasta la API de cada exchange antes de decidir.
¿Con qué frecuencia cambian las API de los exchanges?
Varias veces al año por exchange: nuevos endpoints, versiones obsoletas y límites modificados. Suscríbete a los anuncios de API de cada exchange y consulta nuestro rastreador de cambios en las API.
