Rate limits and quotas
Request rate limits
| Endpoint | Limit | Over the limit |
|---|---|---|
POST /v1/e (tracking) | 60 requests per minute per IP and API instance | 429 (bodyless); the SDK keeps the data and retries with the next send |
POST /v1/cb (conversion beacon) | 4 per minute per IP | 429 (bodyless) |
POST /mcp | 120 requests and 60 tool calls per minute per principal | 429 with Retry-After |
| Login, sign-up, magic links | 10 failures per IP or 20 per account in 15 minutes | 429 with Retry-After |
POST /oauth/register (dynamic client registration) | 20 per hour per IP, 300 per day in total | 429 |
JSON endpoints that apply a limit send RateLimit and RateLimit-Policy headers (IETF draft
format) so clients can slow down before they hit it. Always honour Retry-After.
Daily ingest budgets
Browser tracking is public, so every project has daily budgets that cap what a single visitor (or a script pretending to be many) can write. They are counted per day in the project time zone:
| Budget | Default | Meaning |
|---|---|---|
pageviewsPerKeyDay | 400 | pageviews per visitor network (IP prefix) and day |
eventsPerKeyDay | 4 000 | events per visitor network and day |
pageviewsPerDay | 25 000 | pageviews of the whole project per day |
eventsPerDay | off | events of the whole project per day |
storedBytesQuota | off | estimated stored bytes of the project (refreshed daily) |
Over a budget the tracking endpoint still answers 204 but stores nothing for that project, so
sites never see errors and attackers learn nothing. GET /v1/projects/{project}/status (and the
dashboard's project status) shows quota.exceeded with the reason. The defaults are product
settings, not engine limits: raise them per project in the project settings or with
PATCH /v1/projects/{project} (settings.limits).
Event-name cardinality
Unregistered custom events are accepted, but a project keeps at most 200 observed event names.
Further new names are dropped and counted (status.eventNames.droppedToday). Register the events
you care about in the event catalog (Custom events) and block the noise.
Deployment storage guard
Self-hosted single-tenant deployments on capped database plans can set X3_STORAGE_LIMIT_BYTES,
X3_STORAGE_CLEANUP_ABOVE_BYTES and X3_STORAGE_PAUSE_ABOVE_BYTES. The guard is off unless
these are set; see Environment variables.