Pular para o conteúdo principal

Limites de taxa

MarkdownChatGPTClaude

Um rate limit define o número máximo de requisições que uma aplicação pode fazer à API dentro de um período de tempo específico. Esse mecanismo é fundamental para manter a saúde geral e a confiabilidade dos serviços.

Por que usamos rate limiting​

Estabilidade e performance da API
  • Evita que um único cliente sobrecarregue os servidores com requisições excessivas.
  • Garante tempos de resposta consistentes e previsíveis para todos os clientes.
  • Protege os serviços de backend contra picos de tráfego inesperados.
  • Mantém um padrão de carga estável e controlado na infraestrutura.
Segurança
  • Fortalece a defesa contra tentativas de ataque, como força bruta.
  • Mitiga o risco de negação de serviço distribuída (DDoS).
  • Reduz o impacto causado por integrações mal implementadas.
  • Limita o dano potencial resultante de credenciais de API comprometidas.
Alocação de recursos
  • Garante acesso equilibrado aos recursos da API para todos os clientes.
  • Evita que o uso abusivo por parte de alguns degrade a experiência de outros usuários.
  • Permite priorizar o tráfego de acordo com critérios e necessidades de negócio.
  • Incentiva práticas de consumo da API mais eficientes e sustentáveis.

Como o rate limiting funciona​

Cada chamada de API conta para o limite permitido de requisições por segundo. O valor padrão é 10 RPS por tenant. Quando o limite é excedido, a API retorna HTTP 429 Too Many Requests.

Confirme com o time da Unico

Os limites exatos são configurados por tenant. Entre em contato com o time da Unico para confirmar os limites aplicados à sua conta antes de dimensionar para integrações de alto throughput.

Tratando erros 429​

Solicite um aumento de rate limit

Se sua operação vai ter um aumento no volume de requisições (temporário ou permanente), notifique o time da Unico para elevar o rate limit do seu ambiente. Essa solicitação deve ser feita antes de o volume efetivamente aumentar, para evitar que sua aplicação fique inoperante.

Revise o comportamento da aplicação
  • Audite seu código para identificar padrões ineficientes de uso da API.
  • Verifique se há loops não intencionais ou chamadas de API redundantes.
  • Distribua as requisições de forma mais uniforme ao longo do tempo, em vez de enviá-las em grandes rajadas.
Implemente cache
  • Faça cache de dados frequentemente acessados que raramente mudam.
  • Use o access token OAuth2 durante todo o seu TTL de 1 hora — não chame POST /oauth2/token por requisição.
  • Implemente estratégias apropriadas de invalidação de cache.
Use webhooks em vez de polling

Assine Webhooks e Eventos para PROCESS_STATE_FINISHED em vez de fazer polling em GET /client/v1/process/\{id\}. Um loop de polling pode facilmente esgotar o orçamento de GET-process em tráfego intenso.

O que acontece quando você atinge o limite​

A plataforma retorna:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
HeaderSignificado
Retry-AfterNúmero de segundos a aguardar antes de tentar novamente. Respeite-o.

Se Retry-After estiver ausente, use backoff exponencial (1s, 2s, 4s, 8s, …) com limite de 60s.

Considerações de concorrência​

Os rate limits limitam requisições por minuto, mas a plataforma também possui limites de concorrência no nível de infraestrutura. Mesmo que você tenha orçamento para 100 requisições/minuto, disparar todas as 100 no mesmo segundo tem mais chance de ser rejeitado do que distribuí-las ao longo do minuto.

Para integrações de alto throughput, busque um RPS constante em vez de rajadas.

A Trully tem suas próprias cotas de entrega para o Webhook V2. Espera-se que o servidor de webhook responda em até 1 minuto; respostas mais lentas são descartadas (o processo do usuário não é afetado). Para processamento consistente, confirme o webhook rapidamente e processe-o de forma assíncrona.

Próximos passos​

Última atualização em