Rate limits

Rate limits protect the API from accidental overload and ensure fair access for every integration. Limits can vary according to the API key, service tier and requested endpoint.

Rate-limit responses

When a limit is exceeded, the API returns:

429 Too Many Requests

The response may include these headers:

Header	Description
RateLimit-Limit	Maximum requests allowed in the current window
RateLimit-Remaining	Requests remaining in the current window
RateLimit-Reset	Time until the current window resets
Retry-After	Time to wait before sending another request

Treat the returned header values as authoritative. Do not hard-code a tier's current limits into client behaviour.

Retry safely

If Retry-After is present, wait for the indicated period before retrying. Without that header, use exponential backoff with jitter.

async function waitBeforeRetry(response, attempt) {
  const retryAfter = Number(response.headers.get('retry-after'));

  if (Number.isFinite(retryAfter)) {
    await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000));
    return;
  }

  const delay = Math.min(1000 * 2 ** attempt, 30000);
  const jitter = Math.floor(Math.random() * 250);
  await new Promise((resolve) => setTimeout(resolve, delay + jitter));
}

Set a maximum number of retry attempts. Repeated immediate retries increase load and delay recovery.

Reduce request volume

• Request only the page size the interface requires.
• Cache responses according to their HTTP caching headers.
• Avoid repeating identical searches unnecessarily.
• Debounce search input in interactive interfaces.
• Reuse previously loaded club details where appropriate.
• Process pagination sequentially.

Separate environments

Use separate keys for development, staging and production. Development traffic should not consume the production application's allowance or interfere with production monitoring.

Contact the API provider if the assigned limit does not match the application's legitimate traffic requirements.