EnglishLimits and securityRate limits

Rate limits

The INFI API enforces per-operation throttling to protect infrastructure.

Defaults

OperationDefault limit
POST /v1/pix200 req/hour per account
POST /v1/withdraw10 req/hour + 2/minute + 1/second per account (anti-burst)
GET /v1/balance, GET /v1/transactions, GET /v1/transactions/:idno aggressive throttle; subject to fair use

The hourly window is fixed per hour (not rolling): counters reset at the UTC hour boundary. The withdrawal anti-burst limits (1/s and 2/min) use short buckets with automatic TTL.

Withdrawals: how to avoid hitting the short limits

The anti-burst limits (1/s, 2/min) protect against aggressive retries and accidental duplication. They do not block idempotent retries: if you resend a request with the same externalRef, INFI returns the original transaction without consuming rate limit. See Idempotency.

Limits are adjustable on request. For larger volumes, contact INFI with your expected traffic.

Response

HTTP/1.1 429
{ "error": "Limite de requisições atingido. Tente em 1 hora." }

Withdrawals have specific messages per window:

  • 1/second: "Aguarde alguns segundos antes do próximo saque."
  • 2/minute: "Muitos saques em curto intervalo. Aguarde alguns instantes."
  • 10/hour: "Limite de saques atingido." or "Muitos saques solicitados. Aguarde alguns minutos."

[TO BE CONFIRMED WITH THE INFI TEAM]: today the response does not include a Retry-After header or a retryAfter in the body. Document when/if added.

Recommended strategy

  • Backoff with jitter when receiving 429. Do not retry immediately in a loop.
  • For batched sending, spread charge creation across the hour.
  • For withdrawals, consider batching during a daily window if you have many payouts.
Limits are per account, not per API key

Multiple API keys of the same account share the same rate-limit bucket. Creating more keys does not increase throughput.

IP allowlistAPI key rotation