APIs de exchanges cripto para arbitragem: REST vs WebSocket, rate limits e API keys seguras Quinta-feira, 1 de Outubro de 2026 – Posted in: Arbitrage Software, cryptoarbitrage software
Conexão com APIs de exchanges cripto para arbitragem: REST, WebSocket, rate limits e latência
Uma oportunidade de arbitragem só existe enquanto o seu bot consegue vê-la e agir sobre ela. As duas coisas dependem de como você se conecta a cada exchange. Este guia explica as escolhas que decidem se uma diferença de preço vira uma ordem executada ou um trade perdido: qual tipo de API usar, como funcionam os rate limits na Binance, Bybit, OKX, MEXC e Gate.io, como criar API keys seguras e onde os milissegundos são gastos.
- Por que a conexão com a API decide os resultados da arbitragem
- REST vs WebSocket: para que serve cada um
- Rate limits nas principais exchanges
- Como criar API keys com segurança
- De onde vem a latência e como reduzi-la
- Como manter a conexão confiável
- Checklist antes de entrar em operação
- Perguntas frequentes
Por que a conexão com a API decide os resultados da arbitragem
A arbitragem entre exchanges parece simples no papel: comprar onde o preço está mais baixo, vender onde está mais alto e ficar com a diferença menos as taxas. Na prática, essa diferença costuma durar de algumas centenas de milissegundos a poucos minutos, e todo o trade acontece por meio das APIs das exchanges. Três fatores técnicos determinam quanto você realmente captura:
- A rapidez com que você vê o preço. Se as suas cotações chegam atrasadas, a diferença que você calcula pode já ter desaparecido.
- A rapidez com que as suas ordens chegam. As duas pernas precisam ser executadas em duas plataformas; a perna mais lenta define o seu preço real de entrada.
- Com que frequência você pode fazer requisições. Os rate limits limitam o número de requisições. Um bot que atinge esses limites é bloqueado justamente quando o mercado está mais agitado e as diferenças são maiores.
Nada disso aparece em um backtest, e é por isso que dois bots rodando a mesma estratégia podem gerar resultados muito diferentes. Se você ainda não mediu as diferenças de preço entre as suas exchanges, comece pelo nosso scanner de arbitragem cripto gratuito: ele mostra quais pares e plataformas geram diferenças de preço grandes o suficiente para cobrir as taxas.
REST vs WebSocket: para que serve cada um
Toda exchange relevante oferece duas formas de comunicação.
REST API funciona no modelo de requisição e resposta. O bot envia uma requisição HTTP assinada (por exemplo, “me envie o order book” ou “coloque esta ordem”) e aguarda a resposta. Cada requisição é independente, fácil de depurar e contabilizada no rate limit.
WebSocket API mantém uma única conexão aberta. Depois que você assina um canal, a exchange envia cada atualização (mudanças no order book, negócios, o status das suas próprias ordens) no momento em que ela acontece. Não há polling nem intervalo cego entre as consultas.
| REST | WebSocket | |
|---|---|---|
| Dados de mercado | Snapshot sob demanda; as mudanças entre as consultas se perdem | Fluxo contínuo de atualizações do order book e dos negócios |
| Uso típico em arbitragem | Arbitragem hedge (entre exchanges), em que as diferenças duram segundos ou mais; saldos; saques | Arbitragem de latência e qualquer estratégia em que as diferenças durem menos de um segundo |
| Pressão sobre o rate limit | Alta: cada consulta de preço consome weight | Baixa para dados: uma assinatura em vez de milhares de requisições |
| Complexidade | Baixa | Maior: reconexões, números de sequência, manutenção do order book local |
A maioria das configurações profissionais combina os dois: WebSocket para dados de mercado e atualizações de ordens, REST (ou o endpoint de trading via WebSocket da exchange, quando disponível) para enviar ordens, e REST para chamadas administrativas lentas, como saldos e transferências.
Essa também é a diferença prática entre os nossos dois bots cripto. O VIP Crypto Arbitrage se conecta via REST a mais de 35 exchanges e foi criado para arbitragem hedge entre exchanges, em que as diferenças persistem por tempo suficiente. O SharpTrader Pro usa feeds WebSocket de mais de 40 exchanges, o que é indispensável para a arbitragem de latência, em que a janela é de 100–500 ms.
Rate limits nas principais exchanges
Os rate limits são o motivo mais comum para bots de arbitragem pararem de funcionar no trading real. Toda exchange contabiliza as suas requisições por endereço IP, por conta (UID) ou por API key, e bloqueia ou bane você quando o limite é ultrapassado. A tabela abaixo resume as regras publicadas no momento em que este texto foi escrito (setembro de 2026). Os limites mudam com frequência, então sempre consulte a documentação da exchange e leia os headers de limite nas respostas reais.
| Exchange | Principais limites REST | O que acontece ao ultrapassar | Detalhes úteis |
|---|---|---|---|
| Binance (Spot) | Request weight de 6.000 por minuto por IP; limites separados para quantidade de ordens. Cada endpoint tem o seu próprio weight | HTTP 429; continuar após o 429 leva ao HTTP 418 e a um ban automático do IP de 2 minutos a até 3 dias para reincidentes | Os headers X-MBX-USED-WEIGHT-* e X-MBX-ORDER-COUNT-* mostram o uso atual; Retry-After indica quanto tempo esperar |
| Bybit (V5) | 600 requisições a cada 5 segundos por IP; limites por UID para trading, por exemplo, criação de ordens 20/s no spot e 10/s em contratos lineares | Limite por IP: HTTP 403 “access too frequent”, liberado após cerca de 10 minutos; limite por UID: retCode 10006 | Headers X-Bapi-Limit, X-Bapi-Limit-Status, X-Bapi-Limit-Reset-Timestamp |
| OKX (V5) | Os limites são definidos por endpoint e por instrumento, e níveis VIP mais altos recebem mais capacidade | Resposta de erro do endpoint; abusos repetidos podem restringir a key | Canais de order book: bbo-tbt (melhor bid/ask, a cada 10 ms), books5 (a cada 100 ms), books (incremental, 100 ms); canais L2 tick-by-tick exigem níveis VIP mais altos |
| MEXC (Spot v3) | Endpoints com weight por IP compartilham 300 de weight a cada 10 segundos; endpoints com weight por UID, 500 a cada 10 segundos | HTTP 429 com Retry-After; violações repetidas levam a bans de IP de 2 minutos a 3 dias |
WebSocket: até 30 streams por conexão, 100 mensagens por segundo; a conexão é fechada após 60 s sem tráfego (responda aos pings) |
| Gate.io (API v4) | Limites publicados por key para endpoints spot públicos e privados, com um limite bem maior para cancelamento de ordens | Requisições próximas do limite de burst são atrasadas; as que o ultrapassam são rejeitadas | WebSocket: até 300 conexões por IP |
Três regras mantêm um bot dentro dos limites:
- Obtenha dados de mercado via WebSocket, não via REST. Um bot que consulta o order book de 20 pares em 5 exchanges a cada 200 ms envia 500 requisições por segundo. Os mesmos dados via WebSocket custam apenas algumas assinaturas.
- Leia os headers de limite e desacelere antes que a exchange faça isso por você. Um bot que reduz o ritmo ao atingir 80% do limite nunca chega a ser banido.
- Separe o tráfego. Use API keys diferentes (ou subcontas) para bots diferentes, para que um script descontrolado não bloqueie a sua key de trading.
Como criar API keys com segurança
Um bot de arbitragem precisa de permissão para ler saldos e enviar ordens. Ele nunca precisa de permissão para saques. Uma key vazada sem direito de saque ainda pode causar perdas com trades ruins, mas não consegue esvaziar a conta.
- Crie uma key por exchange e por bot, e dê a ela o nome do bot e do servidor.
- Ative apenas leitura e trading spot/futuros. Mantenha os saques desativados.
- Restrinja a key ao endereço IP da sua VPS. A maioria das exchanges oferece whitelist de IP; uma key limitada a um único IP é inútil em qualquer outra máquina.
- Armazene os segredos criptografados no servidor, nunca em capturas de tela, chats ou documentos compartilhados.
- Troque as keys após qualquer mudança na equipe, migração de servidor ou suspeita de vazamento, e exclua as keys que você não usa mais.
- Para estratégias separadas, use subcontas: elas isolam saldos e rate limits.
De onde vem a latência e como reduzi-la
Do momento em que o preço muda na exchange até o momento em que a sua ordem é executada, o tempo é gasto em cinco etapas: a atualização de mercado viaja até o seu servidor, o seu bot detecta a diferença, a ordem assinada faz o caminho de volta, a exchange a executa no matching e a confirmação retorna. Em um bot bem escrito, o processamento leva poucos milissegundos. Normalmente é a rede que domina.
- Hospede o bot perto da exchange. A maioria das grandes exchanges roda seus matching engines em regiões de nuvem específicas (muitas em Tóquio, Singapura ou Hong Kong). Uma VPS na mesma região pode reduzir o tempo de ida e volta de dezenas de milissegundos para poucos. O nosso guia de velocidade de VPS explica como medir isso.
- Em estratégias com várias exchanges, escolha a localização que minimiza a perna mais lenta, e não a média: o trade é tão rápido quanto a sua execução mais lenta.
- Mantenha as conexões ativas. Reutilize conexões HTTPS (keep-alive) e pré-assine o que for possível; abrir uma nova conexão TLS para cada ordem adiciona uma ida e volta inteira a mais.
- Meça continuamente. Registre o timestamp da exchange de cada atualização em relação ao seu relógio local (sincronizado via NTP) e acompanhe a idade das cotações com as quais o seu bot opera.
Como manter a conexão confiável
Conexões WebSocket caem. As exchanges fecham streams ociosos, reiniciam servidores e limitam o tempo de vida das conexões. Um bot robusto se prepara para isso:
- Heartbeats: responda aos pings (a MEXC fecha a conexão após 60 segundos sem tráfego) e envie os seus próprios, se a exchange exigir.
- Verificação de sequência: streams incrementais de order book trazem IDs de atualização. Se faltar algum, descarte o book local e ressincronize a partir de um snapshot novo, em vez de operar com um book corrompido.
- Reconexão automática com back-off: reconecte rapidamente, mas não em um loop apertado; a Bybit, por exemplo, limita novas conexões por janela de 5 minutos.
- Proteção contra dados desatualizados: se nenhuma atualização de um par chegar dentro de um tempo definido, pare de operar esse par até o stream se recuperar.
- Reconciliação do estado das ordens: após uma reconexão, consulte as ordens abertas e as posições via REST antes de enviar qualquer coisa nova, para que um hedge parcialmente executado nunca seja esquecido.
- Acompanhe os avisos de mudança das APIs. As exchanges descontinuam endpoints e alteram limites várias vezes por ano. O nosso rastreador de mudanças nas APIs das exchanges cripto reúne esses anúncios em um só lugar.
Checklist antes de entrar em operação
- Diferenças de preço confirmadas nos seus pares com o scanner, já descontadas as taxas.
- Uma API key por exchange: apenas trading, saques desativados, whitelist de IP configurada.
- Dados de mercado via WebSocket; chamadas REST limitadas a ordens e dados da conta.
- Headers de rate limit registrados em log; o bot desacelera antes de atingir 80% do limite.
- VPS na região que minimiza a perna mais lenta; tempos de ida e volta medidos.
- Proteções de reconexão, ressincronização e dados desatualizados testadas cortando a rede de propósito.
- Primeira execução real com o tamanho mínimo e, depois, comparação das execuções com os preços que o bot viu.
Deixe o software cuidar da infraestrutura
Gerenciamento de conexões, assinatura de requisições, rate limits e reconexões já vêm integrados aos nossos bots. Comece pelo scanner gratuito e depois escolha o bot que combina com a sua estratégia.
Scanner de arbitragem cripto gratuito Compare os bots de arbitragem cripto
Perguntas frequentes
Preciso de WebSocket para arbitragem cripto?
Para arbitragem de latência, sim: a oportunidade dura menos de um segundo e o polling não consegue vê-la a tempo. Para arbitragem hedge (entre exchanges), em que as diferenças persistem por segundos ou minutos, REST é suficiente, mas o WebSocket ainda reduz o consumo do rate limit.
Por que o meu bot recebe erros HTTP 429 ou 418 na Binance?
429 significa que você ultrapassou um limite de requisições; 418 significa que o IP foi banido porque as requisições continuaram após o 429. Passe os dados de mercado para WebSocket, respeite o header Retry-After e desacelere antes de atingir o limite.
Uma API key de arbitragem deve permitir saques?
Não. Trading e leitura são suficientes. O rebalanceamento entre exchanges pode ser feito manualmente ou por meio de um processo separado e rigorosamente restrito.
Qual é a melhor localização de servidor para arbitragem entre várias exchanges?
Aquela que minimiza a perna mais lenta do seu trade. Meça os tempos de ida e volta das regiões candidatas até a API de cada exchange antes de decidir.
Com que frequência as APIs das exchanges mudam?
Várias vezes por ano em cada exchange: novos endpoints, versões descontinuadas e limites alterados. Assine os anúncios de API de cada exchange e consulte o nosso rastreador de mudanças de API.
