Rate Limits
Per-project, per-endpoint request limits and how to handle 429.
Requests are rate-limited per project, per endpoint, in a fixed 60-second window. Each endpoint keeps its own counter, so traffic to one endpoint does not consume another's budget. Path parameters (e.g. card IDs) are normalized, so all calls to the same endpoint share one counter regardless of the specific resource.
| Endpoint type | Limit |
|---|---|
| General endpoints | 100 requests / minute |
Card sensitive data (GET /cards/{cardId}/sensitive) | 70 requests / minute |
Funds movement (POST /cards/{cardId}/funding, POST /cards/{cardId}/withdrawal) | 70 requests / minute |
Response headers
Every response reports your current budget:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the window |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | Epoch milliseconds when the window resets |
When you exceed a limit
The API returns 429 Too Many Requests with a message indicating how many seconds to wait. Use exponential back-off and retry after the window resets (see X-RateLimit-Reset); your client should never crash on 429.
Prefer webhooks over polling to track state changes (card status, KYC, transactions). They are real-time and do not consume your rate-limit budget.