client_id pode fazer por minuto. Ao ultrapassar esse teto, a API responde 429 em
vez de processar a chamada — por isso vale desenhar sua integração para respeitar os limites desde o
início, e não apenas reagir quando o erro aparece.
Esta página descreve os limites de cada ambiente, os headers que informam seu consumo em tempo real, o
que esperar quando o limite é excedido e as boas práticas para operar em alto volume sem esbarrar no teto.
Limites por Ambiente
Headers de Resposta
Toda resposta inclui headers de rate limit:Quando o Limite é Excedido
Throttling da DATAPREV no E-Consignado
O rate limit acima é da borda da API Zipdin. No E-Consignado, há um segundo ponto de limitação fora do controle da Zipdin: a própria DATAPREV pode responder429 para o Dataprev Controller
durante a obtenção do token de autorização, em picos de volume.
Quando isso acontece, você não recebe um 429 — o Dataprev Controller repassa a limitação da
DATAPREV como 502 Bad Gateway com o erro token_acquisition_failed:
Boas Práticas
1
Respeite o Retry-After
Quando receber 429 da API Zipdin, aguarde o tempo indicado no header
Retry-After.2
Monitore os headers
Acompanhe
X-RateLimit-Remaining para evitar atingir o limite.3
Use cache
Cache respostas de consultas frequentes (ex: dados de conveniada).
4
Batch quando possível
Agrupe operações em lote em vez de chamadas individuais.
Para necessidades acima de 500 req/min em produção, entre em contato com
o time de integrações para discutir um plano dedicado.