Rate limits
La API INFI aplica throttling por operación para proteger la infraestructura.
Por defecto
| Operación | Límite por defecto |
|---|---|
POST /v1/pix | 200 req/hora por cuenta |
POST /v1/withdraw | 10 req/hora + 2/minuto + 1/segundo por cuenta (anti-burst) |
GET /v1/balance, GET /v1/transactions, GET /v1/transactions/:id | sin throttle agresivo; sujeto a fair use |
La ventana horaria es fija por hora (no rolling): los contadores se reinician al cambiar la hora UTC. Los límites anti-burst de retiro (1/s y 2/min) usan cubetas cortas con TTL automático.
Los límites anti-burst (1/s, 2/min) protegen contra reintentos agresivos y duplicación accidental. No bloquean reintentos idempotentes: si reenvías un request con el mismo externalRef, INFI devuelve la transacción original sin consumir rate limit. Ver Idempotencia.
Los límites son ajustables a pedido. Para volúmenes mayores, contacta a INFI con la expectativa de tráfico.
Respuesta
HTTP/1.1 429
{ "error": "Limite de requisições atingido. Tente em 1 hora." }Los retiros tienen mensajes específicos por ventana:
- 1/segundo:
"Aguarde alguns segundos antes do próximo saque." - 2/minuto:
"Muitos saques em curto intervalo. Aguarde alguns instantes." - 10/hora:
"Limite de saques atingido."o"Muitos saques solicitados. Aguarde alguns minutos."
[POR CONFIRMAR CON EL EQUIPO INFI]: hoy la respuesta no trae encabezado
Retry-AfterniretryAfteren el cuerpo. Documentar cuando/si se añade.
Estrategia recomendada
- Backoff con jitter al recibir
429. No reintentes inmediato en bucle. - Para envíos por lote, distribuye la creación de cobros a lo largo de la hora.
- En retiros, considera batching durante una ventana diaria si tienes muchos pagos.
Múltiples API keys de la misma cuenta comparten el mismo cubeto de rate limit. Crear más claves no aumenta el throughput.