---
title: Limites de taxa
description: Limites de taxa por contrato, o header Retry-After, e padrões para ficar dentro do orçamento.
canonical: https://developer.unico.io/pt-BR/developers/start/rate-limits
locale: pt-BR
generated_by: markdown-export
---

- [/pt-BR/](/pt-BR/)
- [Começar](/pt-BR/developers/start/)
- Limites de taxa

**Nesta página# Limites de taxa

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 UnicoOs 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](/pt-BR/developers/webhooks-and-events) 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 RequestsRetry-After: 12
```

HeaderSignificado`Retry-After`Nú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.
### Entrega de webhook do Magic Link​

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​

[Autenticação](/pt-BR/developers/start/authentication) — estratégia de cache do token.
[Webhooks e Eventos](/pt-BR/developers/webhooks-and-events) — substituindo polling por push.
[Códigos de erro > Política de retry](/pt-BR/developers/start/error-codes#retry-policy) — quando (e quando não) tentar novamente.
Última atualização em 8 de out. de 2026**