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

# Rate Limits

> Per-key and per-org rate limits, the Retry-After header, and how to handle 429 responses.

HASP enforces rate limits at two scopes — **per API key** and **per organization** — plus a separate per-cycle spend cap. All applicable limits must pass for a request to proceed.

## The two scopes

| Scope              | What it protects against                                                                                                         |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| **Per-key**        | A single misbehaving key — a buggy loop or a leaked credential — overwhelming the system.                                        |
| **Per-org bucket** | Load spread across many keys overwhelming upstream capacity. The org bucket is the aggregate ceiling for the whole organization. |

A per-key cap can never exceed the org bucket: the org-tier bucket is the hard upper bound, and per-key limits are carved out beneath it. Raising a per-key cap above what the org's tier allows is a tier-gated feature, not a per-key setting.

## Per-org request limits

Requests-per-minute and daily request caps are enforced on a **per-org bucket**, shared by every API key in the org, and scale by your **API tier**:

| API tier   | Requests per minute | Daily requests | Tokens per minute |
| ---------- | ------------------- | -------------- | ----------------- |
| Developer  | 60                  | 5,000          | 100,000           |
| Growth     | 500                 | 50,000         | 500,000           |
| Scale      | 2,000               | 500,000        | 2,000,000         |
| Enterprise | 5,000               | 2,000,000      | Unlimited         |

Tiers not listed fall through to the default (60 RPM / 5,000 daily). Issuing more keys does not raise the bucket. A per-key ceiling can be configured on top of this, but it can only tighten what that key may draw — never exceed the org bucket.

### Tokens per minute

The tokens-per-minute column above is the org-level ceiling that per-key TPM caps are carved out beneath. A per-key cap can tighten it for that key; it can never exceed it.

## Handling `429`

When a limit is hit, the response is a `429` with a retryable error:

```json theme={null}
{
  "success": false,
  "error": {
    "code": "RATE_LIMITED",
    "type": "rate_limited",
    "message": "Too many requests. See Retry-After header.",
    "retryable": true
  }
}
```

The **`Retry-After`** header (RFC 6585) carries the wait in seconds. To handle `429` correctly:

<Steps>
  <Step title="Read Retry-After">
    Wait the number of seconds in the `Retry-After` header before retrying.
  </Step>

  <Step title="Back off if no value is present">
    If neither is set, use exponential backoff with a ceiling rather than retrying immediately.
  </Step>

  <Step title="Respect the bucket">
    Persistent `429`s mean you are at the org or tier ceiling — spread load over time or move up a tier rather than retrying harder.
  </Step>
</Steps>

Responses also carry rate-limit headers (`X-RateLimit-Remaining-Requests`, `X-RateLimit-Reset-Requests`, and token-level equivalents) so you can throttle proactively before hitting a limit.

## Spend cap is a separate limit

A dollar spend cap is independent of RPM/TPM — it protects the bill across a billing cycle, not against burst traffic. When the cap is reached, requests return `402 AI_CREDITS_EXHAUSTED` with an `error.details.cycle_reset_at` timestamp. Spend caps are configured in **Settings → Billing**.

## Full reference

For response-header details and per-org aggregate RPM figures, see the AI API rate-limits reference:

<Card title="AI API Rate Limits" icon="gauge" href="/ai-api/reference/rate-limits">
  The full three-layer model, response headers, and the spend-cap behavior.
</Card>