Skip to main content

Rate Limiting

Quick Reference

WhatA55 API rate limiting policy and retry strategies
WhyAvoid service disruption during high-traffic periods
Reading Time7 min
DifficultyIntermediate
PrerequisitesWorking API integration

Policy

ParameterValue
Rate limit100 requests per minute per API key
WindowRolling 60-second window
ScopePer client_id across all endpoints
Response on limitHTTP 429 Too Many Requests

Rate Limit Headers

Every API response includes rate limit headers:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1711036800
Content-Type: application/json
HeaderDescription
X-RateLimit-LimitMaximum requests allowed per window
X-RateLimit-RemainingRequests remaining in current window
X-RateLimit-ResetUnix timestamp when the window resets

HTTP 429 Response

When you exceed the limit:

{
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Too many requests. Retry after 23 seconds.",
"details": [
{
"field": "rate_limit",
"reason": "100 requests per minute exceeded"
}
]
},
"request_id": "req_abc123..."
}

The Retry-After header indicates how many seconds to wait:

HTTP/1.1 429 Too Many Requests
Retry-After: 23
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1711036823

Retry Strategy with Exponential Backoff

#!/bin/bash
MAX_RETRIES=3
RETRY_DELAY=1

for i in $(seq 1 $MAX_RETRIES); do
RESPONSE=$(curl -s -w "\n%{http_code}" \
-X POST "https://sandbox.api.a55.tech/api/v1/bank/wallet/charge/" \
-H "Authorization: Bearer ${A55_ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"amount": "100.00", "currency": "BRL"}')

HTTP_CODE=$(echo "$RESPONSE" | tail -1)
BODY=$(echo "$RESPONSE" | head -n -1)

if [ "$HTTP_CODE" -ne 429 ] && [ "$HTTP_CODE" -lt 500 ]; then
echo "$BODY"
exit 0
fi

echo "Attempt $i failed (HTTP $HTTP_CODE). Retrying in ${RETRY_DELAY}s..."
sleep $RETRY_DELAY
RETRY_DELAY=$((RETRY_DELAY * 2))
done

echo "All retries exhausted"
exit 1

Best Practices

  1. Read rate limit headers — Track X-RateLimit-Remaining and slow down before hitting zero
  2. Never retry 4xx errors (except 429) — Client errors indicate a bug in your request, not a transient failure
  3. Add jitter to backoff — Prevents thundering herd when multiple clients retry simultaneously
  4. Use a request queue — Smooth out traffic spikes by queuing requests and draining at a controlled rate
  5. Cache where possible — Cache GET responses (wallet details, charge status) to reduce request volume
  6. Batch operations — If you need to create many charges, space them across the window rather than sending all at once