Skip to main content

Rate Limiting

Understanding Anton API rate limits, rate limit headers, and how to handle 429 responses.

Written by Ryan O
Updated today

Overview

The Anton Payments API enforces rate limits to ensure platform stability and fair usage across all merchants. Rate limits are applied per merchant (per API key) and measured in requests per minute.

Current Limits

The default rate limit is 1,000 requests per minute per merchant. This applies across all API endpoints. If you need higher limits for your use case, contact your account manager to discuss your requirements.

Rate Limit Headers

Every API response includes headers that let you monitor your current usage:

Header

Description

X-RateLimit-Limit

Maximum number of requests allowed per window

X-RateLimit-Remaining

Number of requests remaining in the current window

X-RateLimit-Reset

Unix timestamp (seconds) when the rate limit window resets

Retry-After

Seconds to wait before retrying (only present on 429 responses)

Handling 429 Responses

When you exceed the rate limit, the API returns a 429 Too Many Requests response:

{
  "error": {
    "message": "Rate limit exceeded. Retry after 30 seconds.",
    "code": "rate_limit_exceeded"
  }
}

When you receive a 429 response:

  1. Read the Retry-After header to determine how many seconds to wait

  2. Pause your requests for that duration

  3. Retry the failed request

  4. If you continue to receive 429s, implement exponential backoff

Best Practices

  • Monitor the headers -- Check X-RateLimit-Remaining in your responses. If it is getting low, slow down your request rate before you hit the limit.

  • Use pagination efficiently -- Set limit=100 on list endpoints to fetch more data per request and reduce total API calls.

  • Batch operations -- If you need to create many payouts, use the batch upload endpoint instead of creating them individually. This is both more efficient and counts as fewer API calls.

  • Cache where possible -- Cache responses for data that does not change frequently (such as corridor lists) to avoid unnecessary API calls.

  • Implement backoff -- Use exponential backoff with jitter when retrying rate-limited requests. This prevents all your retries from hitting the API at the same time.

  • Distribute requests -- If you have scheduled jobs that make many API calls, stagger them rather than running them all at the same moment.

Sandbox vs Production

Sandbox environments have relaxed rate limits to facilitate development and testing. Production environments enforce the limits described above. Make sure your integration handles rate limiting correctly before going live.

Did this answer your question?