Rate limits & quotas

Stawka enforces two limits on every keyed request:

• A per-minute rate limit — protects against bursts.
• A monthly quota — meters total usage for billing.

Both are scoped per organization. Multiple keys on the same org share the same buckets.

Tiers

Plan	Requests / minute	Requests / month
Free	5	200
Hobby	600	50,000
Pro	6,000	2,000,000

The tier comes from your org’s current subscription (or free for orgs without an active subscription). Changing plans via the Stripe Customer Portal flips the cap on the next request — cached key state is invalidated when the subscription webhook lands, so you don’t have to wait for TTL expiry.

When you hit a per-minute limit

HTTP/1.1 429 Too Many Requests
Retry-After: 23
content-type: application/json

{ "error": "RATE_LIMITED" }

Retry-After is the number of seconds until the current minute bucket rolls over. Back off and retry.

When you hit a monthly quota

HTTP/1.1 429 Too Many Requests
Retry-After: 198473
X-Quota-Limit: 50000
X-Quota-Remaining: 0
content-type: application/json

{ "error": "QUOTA_EXCEEDED" }

Retry-After is the number of seconds until the start of the next CET month (Europe/Warsaw, DST-aware). The two X-Quota-* headers tell you the cap and how much you have left (always 0 on a quota-exceeded response, but they also appear on successful responses near the limit).

Cache hits are free

/rates and /fx responses are cached at the edge for up to one hour plus a stale-while-revalidate window. Edge-cached responses do not consume your rate-limit or quota — only requests that actually reach the Stawka worker count. In practice this means a busy client polling /rates once a minute uses far fewer than 1,440 quota units per day.

/vies/* responses are also cached, but per (country, vat) pair — re-validating the same VAT number is free for the cache TTL.