La mayoría de las personas que fallan en su primera llamada a la API de un exchange no fallan por la lógica de trading. Fallan por un reloj desincronizado 40 segundos, una casilla de permiso que nunca marcaron o un handshake de WebSocket al que le falta una cabecera. La mecánica de cómo llamar a la API de un exchange de criptomonedas es lo suficientemente sencilla como para explicarla en una página; son las protecciones alrededor de la llamada las que deciden si devuelve datos o un código de error.
Esta guía explica qué es una API de exchange, cómo se ensambla realmente una solicitud, qué permisos habilitar y dónde se comprometen realmente las claves API. Todas las cifras específicas de la plataforma a continuación provienen de la documentación de la API de spot y futuros de WEEX, actualizada por última vez el 14-04-2026, y reflejan lo publicado hasta agosto de 2026. Los límites de tasa y los modelos de permisos difieren entre exchanges y cambian con el tiempo; consulte la documentación en vivo antes de desarrollar basándose en cualquier cifra aquí.
Una API de exchange es un conjunto de endpoints que permiten al software hacer lo que harías haciendo clic: obtener precios, leer tu saldo, colocar y cancelar órdenes, y transmitir datos de mercado en vivo. Reemplaza al navegador, no al exchange.
La división que más importa para una primera llamada es pública frente a privada. Los endpoints públicos entregan datos de mercado a cualquiera. Los endpoints privados tocan tu cuenta y requieren una solicitud firmada y autenticada.
| Tipo de endpoint | Qué cubre | Autenticación necesaria |
|---|---|---|
| Público | Precios, velas, profundidad del libro de órdenes, configuraciones de pares, hora del servidor | Ninguna |
| Privado | Saldos, posiciones, colocación de órdenes, cancelación, historial de operaciones | Clave API, firma, marca de tiempo, frase de contraseña |
Dos cosas que una API de exchange generalmente no hace: no te da una estrategia y, en WEEX, no te da un interruptor de retiro; los tipos de permiso de clave API documentados cubren solo lectura y trading. Esa distinción importa más de lo que parece, y vuelve a aparecer a continuación.

Un límite más que vale la pena conocer antes de planificar tu stack: WEEX actualmente no admite trading mediante webhooks de TradingView ni el protocolo FIX. Si tu flujo de trabajo previsto depende de cualquiera de ellos, esa decisión se toma ahora, no después de haber escrito una integración.
Una llamada a una API privada es una solicitud HTTPS normal que lleva cuatro piezas de prueba. Haz las cuatro bien y la llamada funcionará; haz una mal y obtendrás un código de error específico que te dirá cuál.
Paso 1 — Crear y almacenar las credenciales. En WEEX, las claves se crean desde Cuenta → Gestión de API. Cada cuenta puede tener hasta 10 grupos de claves API. La creación devuelve tres valores: una APIKey (el identificador público), una SecretKey (usada para firmar) y una Passphrase que defines tú mismo. La Passphrase no se puede recuperar ni modificar; si la pierdes, tu única opción es eliminar la clave y crear una nueva. Mantenla alfanumérica; los documentos de WEEX aconsejan específicamente no usar caracteres especiales.
Paso 2 — Construir la cadena a firmar. WEEX concatena, en orden: la marca de tiempo en milisegundos, el método HTTP en mayúsculas, la ruta de la solicitud, luego la cadena de consulta precedida por un signo de interrogación si existe, y luego el cuerpo de la solicitud si existe. Para una solicitud de profundidad que produce algo como 1591089508404GET/api/v3/market/depth?symbol=BTCUSDT&limit=20. El orden no es negociable, y tampoco lo es el caso: los símbolos deben estar en mayúsculas, y un btcusdt en minúsculas devuelve un símbolo no válido en lugar de una pista útil.
Paso 3 — Firmarla. Hashea la cadena con HMAC SHA256 usando tu SecretKey, luego codifica el resultado en Base64. Ese valor va en la cabecera ACCESS-SIGN junto con ACCESS-TIMESTAMP. La especificación de firma completa se encuentra en los documentos de WEEX y vale la pena leerla línea por línea; la construcción de la firma es donde fallan la mayoría de las primeras integraciones.
Paso 4 — Enviarla, luego espera 15 minutos si falla. Este es el paso sobre el que nadie te advierte. Una clave API recién creada o modificada tarda aproximadamente 15 minutos en propagarse por los sistemas de WEEX. Los desarrolladores suelen perder una tarde depurando una firma que era correcta todo el tiempo, en una clave que simplemente aún no estaba activa.
Una nota sobre el reloj, porque es el fallo autoinfligido más común: las solicitudes se rechazan si la marca de tiempo se desvía más de 30 segundos de la hora del servidor. Si tu máquina se desvía (las instancias VPS baratas se desvían constantemente), consulta el endpoint de hora del servidor y sincronízate con él en lugar de confiar en el reloj local.
El principio rector es el privilegio mínimo. Una herramienta que solo lee saldos nunca debería tener derechos de trading. WEEX aplica esto haciendo que los permisos sean independientes en lugar de acumulativos, y estableciendo por defecto las nuevas claves como de solo lectura.
| Permiso | Qué permite | Uso típico |
|---|---|---|
| Solo lectura (por defecto) | Solo consultar endpoints: saldos, posiciones, historial de operaciones. Sin órdenes. | Paneles de cartera, sincronización de impuestos y libros contables, análisis de mercado |
| Spot | Colocar y cancelar órdenes spot, consultar activos spot | Bots de spot, reequilibrio automatizado |
| Futuros | Abrir y cerrar posiciones, establecer TP/SL, consultar posiciones | Cobertura, estrategias de contratos de mayor frecuencia |
Solo lectura es la configuración en la que la mayoría de los usuarios deberían detenerse. Si estás alimentando un rastreador de cartera, una herramienta de impuestos o un panel de monitoreo, una clave de solo lectura hace el trabajo sin riesgo de que una credencial filtrada lleve a una posición perdida.
Si necesitas hacer trading, habilita exactamente un mercado. Un bot de spot con permiso de Futuros adjunto está asumiendo un riesgo que nunca usará. Cuando una orden devuelve el error -1052 (permisos insuficientes), la causa es casi siempre esta casilla de verificación: la clave se creó antes de que se seleccionara el permiso de trading, o el permiso se otorgó para el mercado incorrecto.
Vincula una lista blanca de IP mientras estás en el flujo de creación. WEEX marca las claves sin restricciones como un riesgo de seguridad en su propia documentación, y la aplicación es real: una solicitud desde una dirección no incluida en la lista blanca devuelve -1056 (IP no válida) independientemente de si la firma es perfecta. Ese es el punto. Una clave en lista blanca que se filtra es una clave que un atacante no puede usar desde su propia infraestructura.
El trading con API es seguro en el sentido de que el diseño de autenticación es sólido: la firma HMAC con una marca de tiempo rodante derrota los ataques de repetición, y el alcance de los permisos limita el radio de explosión. Es inseguro en el sentido de que casi todas las pérdidas del mundo real provienen de cómo se manejó la clave, no del protocolo.
Las rutas de filtración que aparecen repetidamente:
Lo que hacen los operadores experimentados es más aburrido de lo que parece: claves separadas por entorno, solo lectura donde no se requiere trading estrictamente, listas blancas de IP en cada clave de trading, credenciales en variables de entorno o un gestor de secretos en lugar de en el código, y rotación periódica. WEEX también requiere la vinculación de teléfono o Google Authenticator antes de que se conceda el acceso a la API; el error -1055 es la plataforma diciéndote que la cuenta aún no está lo suficientemente protegida.
Un riesgo operativo que se subestima: tu propio bot. Un bucle sin manejo de errores que dispara órdenes de cancelar y reemplazar a toda velocidad alcanzará los límites de tasa, será estrangulado a mitad de la estrategia y te dejará con una posición que el código cree que cerró. La guía para desarrolladores de WEEX es explícita en que el trading con API conlleva un alto riesgo y que el manejo de errores pertenece al código desde el primer día, no después del primer incidente.
Los límites de tasa son donde "funcionó en las pruebas" se convierte en "dejó de funcionar en producción". WEEX aplica dos medidores separados: peso basado en IP para la mayoría de los endpoints, y conteos de órdenes basados en cuenta para la colocación de órdenes. La colocación de órdenes no consume peso de IP, por lo que los dos presupuestos se gastan de forma independiente.
| Tipo de negocio | Operación | Límite documentado |
|---|---|---|
| Trading spot | Colocar orden | 100 solicitudes / 10s |
| Trading spot | Cancelar orden | 80 / 10s, o 200 / 1 min |
| Trading futuros | Colocar orden | 300 solicitudes / min |
| Conexión de red | Peso de IP REST | 500 peso / 10s por IP |
| WebSocket | Conexiones simultáneas | 20 por IP |
Fuente: Preguntas frecuentes sobre la API de spot y futuros de WEEX, última actualización 14-04-2026.
Excede un límite y obtendrás un HTTP 429 más una prohibición de 10 segundos. No tienes que adivinar qué tan cerca estás: cada respuesta lleva cabeceras que informan el consumo: X-USED-WEIGHT y X-REMAINING-WEIGHT para el peso de IP, X-ORDER-COUNT y X-ORDER-REMAINING para los conteos de órdenes, cada uno con el intervalo como sufijo (X-USED-WEIGHT-1M cubre el minuto anterior). Leer esas cabeceras y retroceder antes de golpear la pared es la diferencia entre una integración resistente y una que es prohibida cada hora ocupada. WEEX publica los pesos por endpoint en sus reglas de restricción de acceso.
Cuando una llamada falla, el código de error nombra la causa con precisión. Estos son los que representan la mayoría de los fallos de primera integración:
| Código | Significado | Causa habitual |
|---|---|---|
| -1046 | Marca de tiempo de solicitud expirada | Reloj local con más de 30s de diferencia de la hora del servidor |
| -1049 | Clave API o frase de contraseña incorrecta | Error tipográfico, o clave aún no propagada (espera 15 min) |
| -1052 | Permisos insuficientes | Permiso de Spot o Futuros no habilitado en la clave |
| -1055 | El usuario debe vincular teléfono o Google Authenticator | 2FA de cuenta no configurado |
| -1056 | Dirección IP no válida | Llamando desde fuera de la lista blanca de IP |
| -1121 | Símbolo no válido | Símbolo en minúsculas, o un par no devuelto por el endpoint de productos |
| HTTP 403 (WebSocket) | Conexión bloqueada | Falta la cabecera User-Agent en el handshake |
Esa última fila es la que desperdicia más horas. El firewall de WEEX rechaza los handshakes de WebSocket que llegan sin una cabecera User-Agent; el contenido puede ser cualquiera, pero el campo debe estar presente. Nada en un tutorial genérico de WebSocket te dirá eso, y el 403 no da ninguna pista. La referencia de códigos de error completa cubre el resto.
Una nota de versión: WEEX recomienda desarrollar contra endpoints V3. V1 y V2 están siendo obsoletos, por lo que una integración escrita contra documentos antiguos está heredando una migración que no necesita.
La secuencia correcta es leer, luego simular, luego operar poco. Saltar a órdenes en vivo con saldo real es cómo un decimal mal colocado se convierte en una orden de mercado.
WEEX agregó endpoints dedicados de paper trading en el lado de futuros, ejecutando el ciclo de vida completo de la orden contra fondos simulados denominados en SUSDT. Puedes consultar un saldo simulado, ver posiciones largas y cortas bajo modo de cobertura, colocar órdenes de mercado y límite, y extraer historial de órdenes simulado: la misma estructura de solicitud y reglas de firma que el trading en vivo, sin activos reales en riesgo. Para depurar la lógica del modo de cobertura o validar que tu firma y manejo de errores realmente funcionan bajo carga, ese es el entorno para romper cosas.
Antes de eso, hay una verificación de cordura gratuita que no cuesta nada: llama a un endpoint público. Obtén la hora del servidor o datos de ticker sin ninguna autenticación. Si eso devuelve un JSON limpio, tu ruta de red y la construcción de la solicitud están bien y cualquier fallo posterior está aislado a la autenticación, lo que reduce la depuración de "todo" a "una cabecera".
Aprender a llamar a una API de exchange de criptomonedas es principalmente aprender sus modos de fallo. La solicitud en sí tiene cuatro componentes: clave, firma, marca de tiempo, ruta, y la firma es un único hash HMAC SHA256 que escribirás una vez y nunca volverás a pensar. Lo que separa una integración que funciona de una rota es la disciplina circundante: claves con alcance de solo lectura a menos que se requiera trading genuinamente, una lista blanca de IP en cualquier cosa que pueda colocar órdenes, un reloj sincronizado con la hora del servidor y lógica de retroceso que lee las cabeceras de peso restante en lugar de martillear hasta ser prohibido.
Si estás empezando desde cero, el orden es: crear una clave de solo lectura, llamar a un endpoint público, llamar a un endpoint de lectura autenticado, luego simular, luego operar con el tamaño más pequeño que permita tu estrategia. El hub de API de WEEX cubre el acceso a spot y futuros en más de 100 activos, y las preguntas frecuentes para desarrolladores responden las preguntas sobre permisos, límites de tasa y formato de símbolos que generan la mayoría de los tickets de soporte.
1. ¿Necesito saber programar para usar una API de exchange?
Para llamadas directas a la API, sí: necesitas suficiente capacidad de programación para construir solicitudes HTTP firmadas y manejar errores. Los no desarrolladores suelen acceder a las API de los exchanges indirectamente a través de rastreadores de cartera de terceros, herramientas de impuestos o bots de trading, donde solo pegas una clave. En ese caso, usa una clave de solo lectura a menos que la herramienta realmente necesite operar.
2. ¿Puede alguien retirar mis fondos si se filtra mi clave API?
No a través de los permisos de clave API documentados de WEEX, que cubren solo lectura y trading; el retiro no está entre los tipos de permiso de API enumerados a partir de la documentación de abril de 2026. Una clave de trading filtrada aún puede causar daño al colocar o cerrar órdenes contra tu cuenta, por lo que una filtración es grave independientemente. Elimina una clave comprometida inmediatamente.
3. ¿Por qué mi clave API funciona en las pruebas pero falla en producción?
Las dos causas más comunes son la lista blanca de IP y los límites de tasa. Una clave en lista blanca para tu máquina de desarrollo devuelve -1056 desde un servidor de producción, y los volúmenes de tráfico que pasan en las pruebas pueden exceder el presupuesto de IP de 500 de peso por 10 segundos bajo carga real.
4. ¿Cuánto tarda en funcionar una nueva clave API?
Aproximadamente 15 minutos en WEEX para que una clave recién creada o modificada se propague por el sistema. Si la autenticación falla inmediatamente después de la creación, espera antes de empezar a reescribir tu código de firma.
5. ¿Cuál es la diferencia entre REST y WebSocket para las API de exchange?
REST es solicitud y respuesta: pides datos o envías una orden y obtienes una respuesta. WebSocket mantiene una conexión persistente abierta y envía actualizaciones a medida que ocurren, que es lo que quieres para precios en vivo, profundidad del libro de órdenes y notificaciones de ejecución. La mayoría de las integraciones usan ambos: REST para órdenes y consultas de cuenta, WebSocket para transmitir datos. WEEX limita las conexiones WebSocket a 20 por IP.
6. ¿WEEX admite alertas de TradingView o API FIX?
Ninguno es compatible en la actualidad. Las estrategias que dependen de la ejecución de webhooks de TradingView o la conectividad FIX necesitan una ruta de ejecución diferente.
Los criptoactivos son volátiles y el trading impulsado por API puede amplificar tanto la velocidad como el tamaño de las pérdidas, hasta e incluyendo la pérdida total de los fondos en tu cuenta de trading. Las estrategias automatizadas fallan de maneras que el trading manual no lo hace: un bot que alcanza un límite de tasa a mitad de la ejecución puede dejar una posición abierta que tu código cree que está cerrada, una desconexión de WebSocket puede suprimir las notificaciones de ejecución mientras las órdenes continúan ejecutándose, y un error de lógica puede colocar cientos de órdenes no deseadas antes de que te des cuenta. El apalancamiento en futuros agrava cada uno de estos. El riesgo de custodia y credenciales es igualmente real: una SecretKey o Passphrase filtrada puede usarse para operar tu cuenta, y una Passphrase perdida no se puede recuperar. Usa permisos de solo lectura donde no se requiera trading, habilita la lista blanca de IP, prueba contra endpoints de paper trading antes de comprometer fondos reales, y nunca dimensiones un primer despliegue en vivo con algo que no puedas permitirte perder. Nada de lo anterior es asesoramiento de inversión.
Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.





























