Rate Limiting
There’s no general rate limit, with one exception, and a reserved right to add merchant-specific limits
No General Rate Limit
Endpoints across both the Payments API and the Disbursement API are not rate-limited by default. There’s no fixed per-minute/per-hour request quota, no rate-limit response headers, and no HTTP 429 Too Many Requests behavior to design around under normal use.
This means you don’t need to build in artificial throttling or backoff logic for standard usage — the earlier guidance to reuse tokens (see Authentication) and to filter list endpoints (see Pagination & Filtering) is about efficiency and good practice, not about staying under a hard cap.
Exception: the Testing Endpoint
The one exception is the Disbursement API’s Testing folder — specifically Repost Transaction (POST /v1/api/disbursement/transactions/repost). This sandbox/QA-only endpoint is rate-limited.
This makes sense given its purpose: it exists purely to re-trigger webhook callbacks for testing (see Testing & Sandbox), not for production traffic, so it’s the one place a limit is enforced to prevent misuse of the callback-resend mechanism.
Reserved Right to Add Merchant-Specific Limits
Even though there’s no general rate limit today, the platform reserves the right to apply a merchant-specific rate limit if abusive or anomalous traffic is detected from your account.
Practical implications:
- Build your integration as if it could be throttled in the future — reuse bearer tokens, filter list endpoints, and avoid unnecessary repeated calls, even though nothing enforces this today.
- If your traffic pattern is unusual (e.g., very high-frequency polling instead of using webhooks, or repeatedly retrying failed calls without backoff), you may trigger a merchant-specific limit even though no blanket limit applies to other merchants.
- Prefer webhooks over polling wherever possible (see Webhooks & Redirects) — this is both more efficient for you and less likely to look like abusive traffic.