> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.epaygames.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.epaygames.io/_mcp/server.

# Rate Limiting

## 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](/authentication)) and to filter list endpoints (see [Pagination & Filtering](/pagination-and-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](/testing-and-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](/webhooks-and-redirects)) — this is both more efficient for you and less likely to look like abusive traffic.

## Summary

| Scope                                                                  | Rate limit?                                                                                            |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Payments API — all endpoints                                           | No general limit                                                                                       |
| Disbursement API — Authentication, Wallet, Disbursement, Authorization | No general limit                                                                                       |
| Disbursement API — Testing → Repost Transaction                        | **Rate-limited**                                                                                       |
| Any endpoint, per-merchant                                             | Not limited by default, but **reserved right** to apply a merchant-specific limit if abuse is detected |