Rate limits & quotas
Per-tier request budgets, how policies match, and the headers on every response.
Pact rate-limits to keep the platform fast and fair for every workspace. Limits apply at two levels — per API key and per workspace — and you can always read your current budget from the response headers.
Response headers
Every authenticated response includes:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed in the current window |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | Unix epoch (seconds) when the window resets |
X-RateLimit-Policy | The endpoint pattern of the matched policy, when specific |
On 429 Too Many Requests, a Retry-After header tells you how many seconds to wait. See rate limits and pagination for a backoff implementation.
Per-tier defaults
Each workspace gets policy defaults from its plan. The default policy (*) applies to every endpoint unless a more specific one overrides it.
| Plan | Default (*) | POST /v1/email/send |
|---|---|---|
| Starter | 60 req / min | 10 req / min |
| Growth | 600 req / min | 100 req / min |
| Enterprise | 6,000 req / min | 1,000 req / min |
Outbound send endpoints carry a tighter limit than reads because they touch deliverability and downstream providers. Enterprise workspaces can request custom policies through their account team.
How policies match
When a request comes in, Pact picks the most specific matching policy:
/v1/email/send → beats /v1/email/* → beats *
So a tight POST /v1/email/send limit applies to sends, while everything else falls back to your default. The matched pattern is echoed in X-RateLimit-Policy.
Per-key limits
Each API key also has its own rate_limit_per_minute, enforced on a rolling 60-second window independently of the workspace policy. This lets you cap a single integration — a nightly export, say — so it can't exhaust the workspace budget shared with your interactive users. Set it when you create the key.
Spread work out
If you're backfilling or syncing large volumes, page in batches and pace your requests against
X-RateLimit-Remaining rather than firing everything at once. A steady stream under the limit
finishes faster than bursts that trip 429 and back off.