Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developers.beta.dealroom.co/llms.txt

Use this file to discover all available pages before exploring further.

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.
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.

​
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. Detect rate limits by HTTP status code alone: 
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:
HeaderDescription
Retry-AfterSeconds to wait before retrying — present only on 429 responses
X-RateLimit-LimitMaximum requests allowed in the current window
X-RateLimit-RemainingRequests remaining in the current window
X-RateLimit-ResetUnix timestamp when the window resets
Not every plan exposes the X-RateLimit-* headers. Treat them as informational — always handle 429 defensively even if the headers are absent.

​
Handling 429 in your client

Use exponential backoff. If Retry-After is present, honor it instead of a fixed delay. 
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 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.