Looking for ePay classic docs? Go to docs.epay.dk
ePay documentationDocsePay documentation

Rate Limits

Our APIs enforce per-merchant rate limits across endpoint categories. Responses include standard headers such as X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and Retry-After to help you handle retries.

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: 60X-RateLimit-Remaining: 12X-RateLimit-Reset: 1735689600Retry-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
  • A batch contains maximum 500 transactions
  • 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.

How is this guide?