Apply rate limits

Rate limits protect the API, the hosted experience, and partner integrations. APIs may return 429 when limited. Respect Retry-After when present, apply bounded retries, and contact support@0bit.io for production support or throughput questions. Contractual limits, SLAs, and support tiers depend on the partner agreement.

Backoff flow

Client behavior

Retry helper

async function requestWithRateLimitBackoff(url: string, init: RequestInit) {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, init);
    if (response.status !== 429) return response;

    const retryAfter = response.headers.get('Retry-After');

    const seconds = Number(retryAfter ?? 2 ** attempt);
    const jitterMs = Math.floor(Math.random() * 500);
    await delay(seconds * 1000 + jitterMs);
  }

  throw new Error('rate_limit_retry_exhausted');
}

0Pools velocity cap

Ordinary request throttling for the 0Pools partner API keys per client IP. Separately, 0Pools can enforce a per-partner notional velocity cap over a rolling 24-hour window. When a partner exceeds its configured notional in that window, transact returns 429; quotes and read endpoints are unaffected.

• The cap is off by default and configured per partner during account review. Exact thresholds are not published.
• Idempotent retries are not double-counted: replaying the same Idempotency-Key for an already-recorded transact does not consume additional notional.
• Treat a velocity 429 like other limits — surface a retry-later state rather than rotating keys, IPs, or accounts.

Abuse-prevention guardrails

• Disable duplicate submit buttons after the first click.
• Coalesce identical capability checks during one page view.
• Put write retries behind idempotency keys.
• Add circuit breakers around repeated 429 or 5xx responses.
• Do not use many client IPs, keys, or accounts to bypass limits.
• Preserve X-Request-Id and timestamps for support.

Related pages