Rate Limits

API rate limits are tied to your project's plan tier. Limits apply independently to read traffic and write traffic, so a heavy export job does not starve registration or scoring updates. Your current limits and live usage are visible in the Platform developer dashboard under Settings → Developer.

Rate limit headers

Every API response includes headers that tell you where you stand:

When you exceed your limit, the API responds with 429 Too Many Requests. Retry after the time indicated by X-RateLimit-Reset.

Handling rate limits

async function fetchWithRetry(url: string, headers: Record<string, string>) {
  const response = await fetch(url, { headers });

  if (response.status === 429) {
    const resetAt = Number(response.headers.get('X-RateLimit-Reset'));
    const waitMs = resetAt * 1000 - Date.now();
    await new Promise(resolve => setTimeout(resolve, waitMs + 100));
    return fetchWithRetry(url, headers); // retry once
  }

  return response;
}

Staying within limits

• Cache read responses. Tournament structures, brackets, and participant lists change infrequently between updates. A short TTL cache (30–60 seconds) dramatically reduces read volume.
• Use webhooks instead of polling. Subscribe to events rather than repeatedly calling the same endpoint to detect changes. See Webhooks.
• Batch writes where possible. Some endpoints accept arrays; use them instead of making one request per item.

Sandbox limits

Every project includes a sandbox environment with its own separate rate-limit budget. Sandbox traffic never counts against production limits. Use it freely for development, testing, and load testing without affecting live tournaments.

Need higher limits?

For programs with unusual traffic patterns — large registration windows, broadcast-day bursts, or partner integrations with large user bases — contact us to discuss a custom Enterprise rate-limit profile.