Rate limits

Limits are applied per API key, per minute.

The limits

Minting is capped harder because each call leaves our network. Reads are served from our own database and are much cheaper.

Why per key, not per IP

A great many Nepali businesses sit behind carrier-grade NAT and share an outbound IP with thousands of unrelated subscribers. An IP-based limit would let one busy shop throttle every other merchant on the same ISP. Keying on your API key means your traffic only ever affects you.

Being limited

{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded",
    "message": "Too many QR requests. Slow down and retry shortly.",
    "doc_url": "https://qora.laayo.com.np/docs/rate-limits"
  }
}

The response carries Retry-After in seconds, plus X-RateLimit-Limit and X-RateLimit-Remaining.

Staying under them

• Use webhooks instead of polling. One QR that is polled every second for five minutes burns 300 requests; the same payment with a webhook costs one.
• If you must poll, back off. Every two seconds for the first minute, then every five to ten. Confirmation does not arrive faster because you asked more often.
• Mint one QR per order, not per render. Store the payment ID against the order and reuse it until it expires.
• Respect Retry-After. Retrying immediately just spends the next window's budget.

async function withBackoff(fn, attempts = 4) {
  for(let i = 0; i < attempts; i++) {
    const res = await fn();

    if (res.status !== 429) return res;

    // Honour the server's own figure rather than guessing.
    const wait = Number(res.headers.get('Retry-After') || 2 ** i);
    await new Promise((r) => setTimeout(r, wait * 1000));
  }

  throw new Error('Still rate limited after retries');
}

Higher limits

If a genuine spike needs more — a festival rush, a ticketed event — contact us before the day rather than during it.