SECURITY

Rate limiting

Every Tab endpoint has a rate limit. Limits protect the infrastructure from abuse, slow down PIN-guessing attacks, and keep one noisy integration from degrading the service for everyone else.

Limit tiers

• Payment execution. The strictest tier — sized to plausible human spending cadence. A misconfigured bot doesn't drain a treasury here.
• Account registration. Tight, to discourage mass handle squatting and burner-account farming.
• Read endpoints. Loose, so a dashboard can poll and a webhook receiver can reconcile without ceremony.

What you'll see when you trip one

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests. Retry in 12 seconds."
  }
}

Backoff guidance

Honour Retry-After. If you'd otherwise retry in a tight loop, apply exponential backoff with a small random jitter on top so a thundering herd of your own services doesn't compound the problem.

Higher limits

Workloads that legitimately need more headroom can write in at hello@thetab.barwith the endpoint you're hitting and the steady-state rate you expect. We'll work out a custom cap that doesn't put the wider service at risk.