Robô de trading e rate limit na API Deriv
Quem escreve o primeiro robô para a Deriv costuma testar com poucas chamadas e tudo funciona. O problema aparece depois: o robô passa a pedir proposta a cada tick, consulta o saldo em loop, abre várias conexões ao mesmo tempo e, de repente, a API começa a responder com erro em vez de dados. Na maioria das vezes, o robô bateu no rate limit, o limite de requisições que a API aceita em um intervalo de tempo.
Este guia explica o que é rate limit na API da Deriv, como descobrir os limites que valem para a sua conexão, quais comportamentos de robô mais causam bloqueio e quais padrões de código ajudam a ficar sempre dentro do limite. Não é sobre ganhar mais; é sobre um robô que não falha no meio de uma operação por excesso de chamadas.
O que é rate limit e por que a API tem um
Rate limit é uma regra do servidor que diz quantas requisições um cliente pode fazer em um período, por exemplo por minuto ou por hora. Toda API pública relevante tem algum tipo de limite, por três motivos: proteger a infraestrutura contra sobrecarga, garantir que um cliente mal escrito não degrade o serviço para os outros e dificultar abuso.
Na Deriv, a comunicação acontece por uma conexão WebSocket. Se você ainda não conhece o protocolo e o formato das mensagens, leia antes o tutorial de Deriv API WebSocket. O ponto importante aqui é que cada mensagem enviada pelo robô (uma proposta, uma compra, uma consulta de saldo) conta como requisição, e os limites são aplicados por tipo de chamada.
Como descobrir os limites da sua conexão
Em vez de chutar números ou confiar em valores copiados de fóruns, consulte a própria API. A chamada website_status devolve, entre outras informações, um objeto api_call_limits com os limites vigentes. Ele costuma trazer grupos como:
- Limite de assinaturas de proposta (
max_proposal_subscription): quantas propostas com assinatura podem ficar ativas ao mesmo tempo. - Requisições gerais (
max_requestes_general, com a grafia da própria API): limites por minuto e por hora para chamadas comuns. - Requisições de resultado (
max_requests_outcome): chamadas ligadas a compra e venda de contratos. - Requisições de preço (
max_requests_pricing): chamadas de cotação.
Os valores podem mudar com o tempo, então a prática mais segura é ler esse objeto quando o robô inicia, registrar os números no log e configurar os limitadores internos a partir deles, sempre com folga. Na dúvida, confira a documentação oficial da API da Deriv.
Como o rate limit aparece no robô
Quando o limite é ultrapassado, a API responde à mensagem com um campo error em vez do resultado esperado, normalmente com um código indicando limite de requisições (como RateLimit) e uma mensagem explicando qual grupo foi excedido. Se o robô não trata esse erro, os sintomas são confusos:
- propostas que nunca chegam e uma estratégia que fica "esperando" para sempre;
- compras que falham justamente quando o sinal aparece;
- saldo e histórico desatualizados na interface;
- reconexões em cascata, que geram ainda mais requisições e pioram o quadro.
Por isso, todo erro devolvido pela API precisa ser registrado com horário, tipo de chamada e req_id. O guia sobre como ler logs de um robô de trading mostra como organizar esses registros para achar o problema depressa.
Os comportamentos que mais causam bloqueio
1. Fazer polling em vez de assinar
O erro mais comum é perguntar repetidamente algo que a API pode enviar sozinha. Pedir ticks sem assinatura a cada segundo, ou consultar o contrato aberto em loop, gasta requisições à toa. A API oferece assinaturas (subscribe: 1) para ticks, propostas, saldo e contratos abertos (proposal_open_contract). Uma assinatura é uma requisição só; as atualizações chegam pela mesma conexão.
2. Uma proposta nova a cada tick
Muitos robôs pedem uma proposta por tick "para ter o preço mais recente". Se a estratégia só decide a cada alguns ticks, isso é desperdício. Peça proposta quando houver intenção real de comprar, ou mantenha uma assinatura de proposta e reutilize o id dela na compra.
3. Assinaturas que nunca são canceladas
Cada assinatura ativa ocupa espaço no limite. Robôs que trocam de ativo ou de contrato sem chamar forget (ou forget_all para um tipo de stream) acumulam assinaturas até estourar o máximo permitido.
4. Várias conexões em paralelo
Abrir uma conexão por operação, por ativo ou por aba aumenta o volume total e dificulta o controle. O padrão saudável é uma conexão persistente por conta, com reconexão controlada. Falamos disso no guia de latência em robô de trading, porque a mesma decisão também reduz atraso.
5. Reconexão sem espera
Quando a conexão cai, reconectar imediatamente e reenviar todas as assinaturas de uma vez gera um pico de requisições. Se a queda se repete, o robô entra num ciclo de reconectar, estourar o limite e cair de novo.
6. Consultas estáticas repetidas
Listas como active_symbols e contracts_for mudam pouco. Consultá-las antes de cada operação é desnecessário; guarde em cache e atualize em intervalos longos ou ao iniciar a sessão.
Padrões de código para respeitar o limite
A ideia central é que o robô controle o próprio ritmo antes que a API precise fazer isso. Três peças resolvem a maior parte dos casos.
Limitador por balde de fichas
O balde de fichas (token bucket) libera um número de requisições por intervalo e acumula folga quando o robô fica ocioso, até um máximo. Toda mensagem passa por ele antes de ir para a conexão. Um exemplo simples em Python:
import time, asyncio
class Balde:
def __init__(self, por_minuto, folga=0.8):
self.taxa = por_minuto * folga / 60.0 # fichas por segundo
self.capacidade = max(1.0, self.taxa * 10)
self.fichas = self.capacidade
self.ultimo = time.monotonic()
async def pegar(self):
while True:
agora = time.monotonic()
self.fichas = min(self.capacidade,
self.fichas + (agora - self.ultimo) * self.taxa)
self.ultimo = agora
if self.fichas >= 1:
self.fichas -= 1
return
await asyncio.sleep((1 - self.fichas) / self.taxa)O parâmetro por_minuto vem do api_call_limits lido na inicialização, e a folga de 80% deixa margem para picos e para chamadas que você não previu. Em robôs com tipos diferentes de chamada, use um balde por grupo de limite.
Espera exponencial com variação aleatória
Quando a API devolver erro de limite ou a conexão cair, espere antes de tentar de novo, dobrando o tempo a cada falha e somando uma pequena variação aleatória:
import random
def espera(tentativa, base=1.0, teto=60.0):
return min(teto, base * 2 ** tentativa) + random.uniform(0, 1)A variação evita que várias instâncias reconectem no mesmo segundo. Depois de reconectar, reenvie as assinaturas aos poucos, passando pelo mesmo balde.
Prioridade para o que envolve dinheiro
Nem toda requisição tem o mesmo peso. Compra, venda e acompanhamento do contrato aberto devem ter prioridade sobre consultas de saldo, histórico ou dados para a interface. Uma fila com duas prioridades garante que, perto do limite, o robô atrase o que é cosmético e não o que protege uma posição.
Nunca repita uma compra sem conferir
Um caso perigoso: o robô envia buy, a conexão cai ou chega um erro ambíguo, e o código simplesmente reenvia a compra. Se a primeira ordem foi executada, agora há duas posições. Antes de repetir qualquer compra, confira o extrato ou a lista de contratos abertos (profit_table, statement ou portfolio) para saber o que de fato aconteceu. Esse passo de reconciliação é uma das camadas descritas no guia de arquitetura de bot de trading.
Como testar o comportamento sob limite
- Use a conta demo e o mesmo código que vai para produção.
- Meça o volume: conte requisições por minuto e por tipo durante uma sessão normal e compare com o
api_call_limits. - Force o erro em ambiente de teste, reduzindo o limitador interno ou simulando respostas de erro, e veja se o robô espera, registra e retoma sem duplicar ordens.
- Simule quedas de conexão e confira se as assinaturas voltam sem pico de requisições.
- Defina uma regra de parada: se os erros de limite se repetirem por vários minutos, o robô deve pausar e avisar, em vez de continuar tentando. Veja critérios no guia de quando pausar o robô de trading.
Robô rodando 24 horas
Em servidores que ficam ligados o tempo todo, pequenos vazamentos de assinatura e reconexões frequentes se acumulam ao longo de dias. Monitore o número de assinaturas ativas, a quantidade de erros por hora e o tempo desde a última reconexão. Se você roda em servidor, o guia de robô 24 horas em VPS traz outros cuidados de operação contínua.
Resumo
Rate limit é o limite de requisições que a API da Deriv aceita por período e por tipo de chamada. Leia os limites com website_status, prefira assinaturas a polling, cancele o que não usa, mantenha uma conexão por conta, controle o ritmo com um balde de fichas, espere de forma exponencial depois de erros e nunca repita uma compra sem conferir o extrato. Teste tudo na conta demo. Um robô bem-comportado com a API não fica mais lucrativo, mas evita falhas técnicas no pior momento. Operar contratos de curto prazo envolve alto risco de perda.
Perguntas frequentes
Qual é o limite de requisições da API da Deriv?
Os limites variam por tipo de chamada e podem mudar com o tempo. A forma confiável de saber os valores atuais é chamar website_status e ler o objeto api_call_limits, que traz os limites por minuto e por hora de cada grupo.
O que acontece quando o robô ultrapassa o rate limit?
A API responde à mensagem com um campo error indicando que o limite foi atingido, em vez de devolver o resultado. O robô precisa tratar esse erro, esperar antes de tentar de novo e registrar o ocorrido no log.
Assinar ticks conta como várias requisições?
Não. Uma assinatura com subscribe: 1 é uma única requisição, e as atualizações seguintes chegam pela mesma conexão. Por isso assinar é muito mais econômico do que pedir o mesmo dado repetidamente.
Posso abrir várias conexões para ter mais limite?
Não é uma boa ideia. Várias conexões aumentam o volume total, dificultam o controle e podem esbarrar em limites aplicados à conta ou ao aplicativo. O padrão recomendado é uma conexão persistente por conta, com limitador interno.
Como evitar compra duplicada depois de um erro de limite ou queda de conexão?
Antes de reenviar uma compra, confira o extrato ou os contratos abertos para saber se a primeira ordem foi executada. Só repita a compra se tiver certeza de que ela não aconteceu.
