Rate limits

Enforcement is server-side and atomic. Per-second limits use a single-statement Postgres counter; monthly quotas use a per-user counter with quota refunds on failed dispatches. All limits are pulled from src/lib/tierLimits.ts.

Per-tier limits

Response headers

Every /v1/* response carries the following (lowercase; HTTP header names are case-insensitive):

• x-ratelimit-limit — current tier's requests per second.
• x-ratelimit-remaining — RPS budget left in the current second.
• x-ratelimit-reset — unix seconds when the RPS window rolls over.
• x-ratelimit-limit-monthly — monthly quota (-1 when unlimited).
• x-ratelimit-used-monthly — successful billable calls this month.
• x-ratelimit-remaining-monthly — limit − used (-1 when unlimited).
• x-akrum-overage — true when this call is served past the included quota (Startup / Growth only).
• retry-after — seconds to wait, present on 429 rate_limit_exceeded.

Overage & hard-stops

• Free — hard-stops at 5,000 successful calls per month with 429 monthly_quota_exceeded. No overage.
• Startup & Growth — additional calls continue to serve, are flagged with x-akrum-overage: true, and are metered to Stripe for graduated billing. Requests are stopped with 429 spend_cap_reached once projected overage would exceed the account's configured monthly spend cap.
• Enterprise — no monthly cap; RPS still enforced at 1,000.

Handling 429s

Back off exponentially. On per-second limits, retry-after: 1 is returned; on monthly / spend-cap 429s the correct action is to upgrade or raise the cap in Billing.