Skip to main content
abadge applies per-principal rate limits at the API edge.

​
Limits

/v1/* and /trpc/* share the same per-principal limit but are independent buckets. A handful of unauthenticated auth routes carry stricter per-IP sub-limits (e.g. sign-in/email 10 / 15 min, request-password-reset 5 / 15 min). Counters reset every minute.

​
Response

When a caller exceeds the limit, the API returns HTTP 429 Too Many Requests with the standard error envelope:
A Retry-After header accompanies every 429. Every response (not just 429s) also carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset so clients can back off before they hit the ceiling.
1

Back off on 429

Counters reset once per minute, so a 60-second retry window is a safe default.
2

Add jitter

Jitter your retries so concurrent clients don’t synchronize.
3

Cache idempotent reads

Cache item metadata and permission lists client-side where you can.
4

Use the SDK

AbadgeAgentClient session refresh has bounded-backoff retries built in.

​
Exclusions

GET /v1/health is excluded from rate limiting and requires no authentication. Use it for liveness checks.

​
What rate limiting does not do

Rate limiting bounds request volume. It does not replace permission checks, capability enforcement, or audit logging — every legitimate request still goes through the full decision flow described in Permissions and capabilities.