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: 5When 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-Afterto 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.
Using the Idempotency-Key Header
Learn how to safely retry requests without creating duplicate payments or operations by using the Idempotency-Key header to ensure consistent, reliable API behavior.
Integrating with e-conomic
This guide explains how to set up the e-conomic integration, allowing you to automatically include payment links on invoices using our payment platform and generate journal drafts in e-conomic when payments are received.