Skip to main content

Rate Limits

Our APIs use rate limits to ensure fair usage and stable performance for all customers. Rate limits apply per merchant and are enforced per endpoint category.

How Rate Limits Work​

Each request consumes from a limit “bucket.” Some limits allow a burst, which lets you temporarily exceed the steady rate before being throttled. If you exceed a limit, the API responds with HTTP 429 and an error code.

Response Headers​

Every rate‑limited endpoint includes these headers:

  • X-RateLimit-Limit: Maximum number of requests allowed in the current window.
  • X-RateLimit-Remaining: Requests remaining in the current window.
  • X-RateLimit-Reset: Unix timestamp (seconds) when the limit fully resets.
  • Retry-After: Seconds to wait before retrying (present when throttled).

Example headers:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 12
X-RateLimit-Reset: 1735689600
Retry-After: 5

When a limit is exceeded, you will receive:

HTTP/1.1 429 Too Many Requests
{
  "success": false,
  "errorCode": "RATE_LIMIT_REACHED",
  "message": "Too many requests"
}

Rate Limit Categories​

Different endpoint categories have different limits. The following limits are currently enforced:

1) Single MIT transactions​

  • Rate: 5 requests / second
  • Burst: 300
  • Ingestion: 300 transactions / minute

2) Batch MIT transactions​

  • Rate: 1 batch / second
  • Ingestion: 30.000 transactions / minute

3) Index endpoints​

  • Rate: 1 request / 5 seconds
  • Burst: 30

4) Resource endpoints​

  • Rate: 5 requests / minute / resource

5) Operation endpoints (capture, void, refund)​

  • Rate: 5 requests / minute / transaction

Note: A burst allows short spikes above the steady rate. After a burst is consumed, requests will be throttled until the bucket refills.

Note: Resource / Operation rate limits are grouped per resource id. Meaning you can capture as many transactions as you need, but cannot capture the same transaction more than 5 times a minute.

Best Practices​

  • Use Retry-After to back off before retrying.
  • Avoid polling - Use webhooks where available.
  • Use batch endpoints for high‑volume processing.
  • Handle 429 responses gracefully with exponential backoff.

If you have a use case that requires higher limits, contact support to discuss options.