> ## Documentation Index
> Fetch the complete documentation index at: https://docs.methodfi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate Limiting

Method enforces rate limits on all API requests to protect platform stability and ensure
fair usage across all customers. Rate limits apply to all environments (Development, Sandbox,
and Production) and all API versions.

## How rate limits work

Rate limits are applied **per API key** within a **60-second rolling window**. Limits are
organized into tiers based on operation type — more sensitive operations (such as payment
creation) have stricter limits, while high-volume read and write operations have more
generous allowances.

Each tier tracks its own counter independently, so usage against one tier does not affect
your capacity in another.

When a rate limit is exceeded, requests matching that tier are blocked for 60 seconds,
after which requests are automatically accepted again.

<Note>
  The same rate limits apply across all environments (Development, Sandbox, and Production).
  Rate limits encountered during testing in Development or Sandbox reflect the same thresholds
  your integration will experience in Production.
</Note>

## Rate limit tiers

| Tier                | Limit (requests per minute) | Description                                                            |
| ------------------- | --------------------------- | ---------------------------------------------------------------------- |
| Payment creation    | 120                         | `POST /payments`                                                       |
| Critical operations | 60                          | Payment deletion and report generation                                 |
| Standard writes     | 6,000                       | Entity and Account operations (create, update, connect, subscriptions) |
| Other writes        | 1,800                       | All other write operations                                             |
| Reads               | 6,000                       | All `GET` requests                                                     |
| Unauthenticated     | 60                          | Per IP address, requests without an API key                            |

Standard write operations are further divided into independent buckets by resource and
operation type — for example, account creation and entity creation each have their own
6,000 rpm allowance and do not compete with each other.

## Rate limit response

When rate limited, the API returns an HTTP `429` status code with the following response body:

```json theme={null}
{
  "success": false,
  "data": {
    "error": {
      "type": "INVALID_REQUEST",
      "code": 429,
      "sub_type": "TOO_MANY_REQUESTS",
      "message": "The maximum request limit for this time has been exceeded. Please re-try your request at a later time."
    }
  },
  "message": "The maximum request limit for this time has been exceeded. Please re-try your request at a later time."
}
```

## Handling rate limits

When you receive a `429` response, the block lasts for 60 seconds. Retrying immediately
will not succeed. We recommend the following approach:

1. **Wait at least 60 seconds** before retrying the request.
2. **Use exponential backoff with jitter** if subsequent attempts are still rate limited.
   Add randomness to retry intervals to prevent multiple clients from retrying in sync.
3. **Combine with [idempotency keys](/2026-03-30/reference/idempotency)** on `POST` requests to ensure
   retried requests are not processed more than once.

<Note>
  If your integration regularly approaches rate limits, consider spreading requests over time
  rather than sending them in bursts. Smoothing traffic reduces the chance of hitting tier
  limits during peak operations.
</Note>

## Enterprise rate limits

Customers with high-volume integrations can request custom rate limits tailored to their usage patterns. Contact your customer success manager or reach out to our team to discuss enterprise rate limit overrides.