Prefer to use /import over /track where you can. We only recommend /track for client-side tracking in an environment for which we don't have SDK support or if you're sending data via some other untrusted environment (eg: third-party webhooks that send data to Mixpanel).
|Events per request||200||2000|
|Authentication||Project Token, intended for untrusted clients.||Project Secret, intended for server-side integration.|
|Content-Type||application/x-www-form-urlencoded||application/json or application/x-ndjson|
|Ingesting historical events||Last 5 days only.||Any time after 1971-01-01.|
Each event has the following size limits:
- Must be smaller than 1MB of uncompressed JSON.
- Must have fewer than 255 properties.
- All nested object properties must have fewer than 255 keys and max nesting depth is 3.
- All array properties must have fewer than 255 elements.
To ensure real-time ingestion and quality-of-service, we have a rate limit of 2GB of uncompressed JSON/minute or ~30k events per second, measured on a rolling 1 minute basis.
We recommend the following when it comes to sending data to our API at scale:
- Send data as quickly as possible with concurrent clients until the server returns 429. We see the best results with 10-20 concurrent clients sending 2K events per batch.
- When you see 429s, employ an exponential backoff with jitter strategy. We recommend starting with a backoff of 2s and doubling backoff until 60s, with 1-5s of jitter.
- We recommend gzip compression and using
Content-Encoding: gzipto reduce network egress and transfer time.
- In the rare event that our API returns a 502 or 503 status code, we recommend employing the same exponential backoff strategy as with 429s.
- Please do not retry validation errors (400 status code), as they will consistently fail and count toward the rate limit.
If you are an Enterprise customer that requires a higher rate limit, please reach out to your CSM with your project_id and use case.