Send batches of events from your servers to Mixpanel.
Each request ingests a batch of events into Mixpanel. We accept up to 2000 events and 2MB uncompressed per request. Events are part of the request body. We support Content-Type application/json or application/x-ndjson:
We also support Content-Encoding: gzip to reduce network egress.
/import requires an Owner or Admin Service Account. project_id, service account username and service account password are required to authenticate a request.
Note: /import also supports Project Secret for legacy reasons. If you do not specify project_id, we will use secret auth.
/import validates the supplied events and returns a 400 status code if any of the events fail validation with details of the error. If some events pass validation and others fail, we will ingest the events that pass validation. When you encounter a 400 error in production, simply log the JSON response, as it will contain the $insert_ids of the invalid events, which can be used to debug.
Each event must be properly formatted JSON.
Each event must contain an event name, time, distinct_id, and $insert_id. These are used to deduplicate events, so that this endpoint can be safely retried.
Each event must be smaller than 1MB of uncompressed JSON.
Each event 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.
This is the name of the event. If you're loading data from a data warehouse, we recommend using the name of the table as the name of the event.
We recommend keeping the number of unique event names relatively small and using properties for any variable context attached to the event. For example, instead of tracking events with names "Paid Signup" and "Free Signup", we would recommend tracking an event called "Signup" and having a property "Account Type" with value "paid" or "free".
This is a JSON object representing all the properties about the event. If you're loading data from a data warehouse, we recommend using column names as the names of properties.
The time at which the event occurred, in seconds or milliseconds since epoch. We require a value for time. We will reject events with time values that are before 1971-01-01 or more than 1 hour in the future as measured on our servers.
distinct_id identifies the user who performed the event. distinct_id must be specified on every event, as it is crucial for Mixpanel to perform behavioral analysis (unique users, funnels, retention, cohorts) correctly and efficiently.
If the event is not associated with any user, set distinct_id to the empty string. Events with an empty distinct_id will be excluded from all behavioral analysis.
To prevent accidental implementation mistakes, we disallow the following values for distinct_id:
We require that $insert_id be specified on every event. $insert_id provides a unique identifier for the event, which we use for deduplication. Events with identical values for (event, time, distinct_id, $insert_id) are considered duplicates and only one of them will be surfaced in queries.
$insert_ids must be ≤ 36 bytes and contain only alphanumeric characters or "-". We also disallow any value for $insert_id from the list of invalid IDs provided for distinct_id above.
Example of a validation error
"error": "some data points in the request failed validation",
"message": "properties.time' is invalid: must be specified as seconds since epoch"
"message": "properties.utm_source is invalid: string should be valid utf8"
"status": "Bad Request"
When any single event in the batch does not pass validation, we return a 400 status code and a response that looks like the above.
failed_records includes one row for each of the failed events, with details about the error we found. If some of the rows passed validation, we will ingest them and return their count in num_records_imported.
If you supply a property ip with an IP address, Mixpanel will automatically do a GeoIP lookup and replace the ip property with geographic properties (City, Country, Region). These properties can be used in our UI to segment events geographically.
This is an example of an event before and after enrichment:
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: gzip to 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 and require a higher limit for a 1-time backfill, please reach out to your sales representative with your project_id and use-case.
$insert_id is required on all events. This makes it safe to retry /import requests. If your events don't already have a unique ID (eg: a UUID/GUID), we recommend computing a hash of some set of properties that make the event semantically unique (eg: distinct_id + timestamp + some other property) and using the first 36 characters of that hash as the $insert_id.
We truncate all strings down to 255 characters. Here's what we recommend for the various cases in which this typically happens:
URLs: We recommend parsing the URL and tracking its individual components (host, path, url params) as properties. This is more useful in analysis, as you can segment events by hostname or a particular URL parameter.
JSON encoded strings: Sometimes a long string may be a JSON object encoded as a string. We recommend parsing the JSON and flattening it into properties to send with the event. This is similarly much more useful in analysis, as you can filter or breakdown by any key within the JSON.
Free text / user generated content: Some long fields may include full-text (eg: a search term or a comment). If this property isn't useful for analysis, we recommend excluding it from tracking to Mixpanel to avoid accidentally sending over any PII.