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

# Rate limits

> How the Dealroom API rate-limits requests, what a 429 response looks like, and how to request higher limits.

Rate limiting is enforced at the Cloudflare edge in front of the API. The exact ceiling
depends on your API key's plan — contact your Dealroom account manager for the specific
numbers attached to your key.

<Note>
  Limits are typically expressed as requests per minute and may be applied per IP, per
  API key, or both. If you're hitting limits unexpectedly, check whether multiple
  applications share the same key.
</Note>

## When you exceed the limit

The API returns **`429 Too Many Requests`**. Because rate limiting is enforced at the
Cloudflare edge — before the request reaches the API server — the response body is a
Cloudflare-generated HTML or JSON payload, not the standard
[error envelope](/mintlify/concepts/errors). Detect rate limits by HTTP status code
alone:

```typescript theme={null}
if (response.status === 429) {
  // Rate limited — back off and retry
}
```

## Response headers

When rate-limit headers are present, Cloudflare emits them on every response — use them to
proactively pace requests rather than waiting for a 429:

| Header                  | Description                                                       |
| ----------------------- | ----------------------------------------------------------------- |
| `Retry-After`           | Seconds to wait before retrying — present only on `429` responses |
| `X-RateLimit-Limit`     | Maximum requests allowed in the current window                    |
| `X-RateLimit-Remaining` | Requests remaining in the current window                          |
| `X-RateLimit-Reset`     | Unix timestamp when the window resets                             |

<Tip>
  Not every plan exposes the `X-RateLimit-*` headers. Treat them as informational —
  always handle `429` defensively even if the headers are absent.
</Tip>

## Handling 429 in your client

Use exponential backoff. If `Retry-After` is present, honor it instead of a fixed delay.

```typescript theme={null}
async function withRetry<T>(fn: () => Promise<T>, maxAttempts = 5): Promise<T> {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err: any) {
      if (err.response?.status !== 429 || attempt === maxAttempts) throw err;
      const retryAfter = Number(err.response.headers["retry-after"]);
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1000
        : Math.min(2 ** attempt * 1000, 30000);
      await new Promise((r) => setTimeout(r, delayMs));
    }
  }
  throw new Error("unreachable");
}
```

## Best practices

* **Batch where possible.** Use [aggregate endpoints](/mintlify/concepts/aggregates)
  instead of fetching individual entities to compute totals.
* **Cache responses.** Most reference data (taxonomy, dimensions) changes rarely —
  cache for the lifetime of your app's request cycle.
* **Use one API key per integration.** Sharing keys across services makes throttling and
  attribution harder to debug.
* **Coalesce parallel calls.** If your dashboard makes 8 parallel aggregate calls per
  page load, that's 8 against the limit. Fan-out is fine; storms aren't.

## Requesting higher limits

If your workload requires sustained higher throughput (data pipelines, periodic exports,
research workloads), contact your Dealroom account manager with:

* The use case and expected request volume (peak RPM, sustained RPM)
* Which endpoints will see the most traffic
* Whether the work can run off-peak

Programmatic data exports are usually better served by the aggregate endpoints or a
custom bulk-export arrangement than by raising raw request limits.