Export your Mixpanel data before the contract ends
A renewal, a pricing change, a data residency requirement or a lock-in review usually makes a full export necessary before the contract ends. Raw events can be pulled through the Mixpanel Raw Event Export API, which returns JSONL with one event per line, including its properties, distinct_id and fire time. Other configuration, such as dashboards, reports, cohorts, saved funnels, annotations and user permissions, is not part of that endpoint and needs a separate inventory and manual or scripted rebuild. Write that inventory down now, because it is the part of the work most likely to be forgotten until the account is closed.
The API sets the schedule more than the tooling does. Export dates are read as UTC for projects created after January 1, 2023, and in the project's timezone for older projects, and both from_date and to_date are inclusive, so confirm which rule applies to your project before you cut date ranges or you will see overlaps or gaps at the boundaries. The raw export allows 60 queries per hour, 3 per second and 100 concurrent queries, and returns HTTP 429 when those limits are exceeded. Projects with EU or India residency must use the data-eu or data-in hosts, so confirm the project's region before scripting anything against the default host.
Plan the full-history extraction as a batch job with one window per range, a retry policy for 429 responses and gzip enabled through the Accept-Encoding header to reduce transfer size. Estimate the number of windows from your retention period and event volume, and ask Mixpanel's account team to confirm any export limits that apply to your plan, since the documented rate limits are the only ones this page relies on. Store each window with its checksum and row count so you can prove completeness later. Keep the exported files in storage that matches your residency obligations, and confirm the retention and deletion rules for those copies with your data protection lead before the source project is closed.
Which Mixpanel data the Raw Event Export API returns
This table lists what the Raw Event Export API returns, how dates and compression behave, and the rate limits that shape a full-history extraction. Read the date and limit rows first, because they decide how you split the export and how long it takes to run. The main takeaway is that the timezone rule depends on when your project was created, so confirm it before you compare counts with another system.
| Attribute | What the API does | What to plan for |
|---|---|---|
| Data type | Raw events with their properties, distinct_id and fire time | Aggregated reports and user profiles are not part of this export, so pull them separately if you need them |
| Export method | Raw Event Export API | Script the calls yourself, because the export is an API request, not a dashboard download |
| Output format | JSONL, one event per line | Write a parser that handles one JSON object per line and stream it to storage rather than loading it all at once |
| Compression | gzip through the Accept-Encoding header | Request gzip to reduce transfer size, then confirm your client decompresses the response correctly |
| Timezone rule | UTC for projects created after January 1, 2023; project timezone for older projects | Check your project creation date and timezone setting before you reconcile counts against other tools |
| Date boundaries | from_date and to_date are both inclusive | Avoid overlapping windows, or you will export the boundary day twice and inflate totals |
| Rate limits | 60 queries per hour, 3 per second and 100 concurrent queries | Build in pacing and retries; a full-history run is bounded by the hourly query cap, not by bandwidth |
| Rate limit response | HTTP 429 when any limit is exceeded | Back off and retry the same window instead of skipping it, then log every window that completed |
| Regional hosts | data-eu and data-in hosts for EU and India residency projects | Confirm your project's region before the first call, because requests to the wrong host will not return your data |
What the raw export does not carry and how to work around it
The Raw Event Export API returns events and their properties, nothing else. Reports, dashboards, cohorts and saved configuration sit outside the event feed, so each one needs a deliberate rebuild or a written record before the Mixpanel project is switched off.
Saved reports and dashboards
Insights reports, funnels, retention charts and dashboards are saved views over the event data, not events themselves, so the raw export does not contain them. Before any cutover, open each dashboard that the business relies on and record its event names, filters, breakdowns, date window and segmentation logic. Capture a screenshot as a visual reference and store the definition in a document or version-controlled file. Then recreate the most important views in the target platform and compare totals for a shared date range to confirm the logic matches.
Cohorts and saved segments
Cohorts are defined by rules over events and properties, and the export carries only the underlying events. A cohort that has been built as a static user list cannot be recovered from the feed, while a rule-based cohort can be rewritten from its logic. List every cohort in use, note whether its membership is dynamic or static, and write its rule as an explicit event and property condition. Recreate each rule in the new platform and check that user counts are close for the same period before relying on them in campaigns or flags.
Alerts, annotations and saved configuration
Alerts, scheduled report emails, annotations, tags, data view settings and custom event definitions are project configuration rather than event data. Mixpanel's export will not return them, and their absence is easy to miss because no error is raised. Inventory these settings from the project admin screens, including who receives each scheduled report and what threshold triggers an alert. Keep the inventory with the migration record so that owners can confirm each item was rebuilt or retired on purpose.
Identity merges and user profiles
The export returns each event with its distinct_id, but the identity merge history and the current user profile properties are held separately. Without the merge history, a user who was merged from an anonymous ID into a known ID may appear as two people in the new platform. Ask Mixpanel's documentation which identity and profile data is available through its other APIs, and decide whether profile properties need a separate export or can be rebuilt from the latest event properties in your own pipeline.
Other data types and endpoints
Teams often assume that the raw event feed is the only export, but Mixpanel may offer other endpoints for profiles, group analytics, lookup tables or aggregated query results. Before planning the extraction, confirm with Mixpanel which data types are available through separate endpoints, which of them need their own credentials or rate limits, and whether they cover the same regional host as the raw export. Treat any data type you cannot export as a documented gap with a named owner.
How date and timezone rules change the extraction
Before you choose any date window, record which timezone rule applies to each Mixpanel project, because it decides what a calendar day means in your export. Mixpanel reads export dates as UTC for projects created after January 1, 2023, and in the project's own timezone for older projects. The project creation date is therefore the setting that matters, not the timezone your analysts use in the dashboard. A project created before 2023 may use a local day boundary, so a window that looks like one UTC day can cut events differently from the same window run against a newer project.
Both from_date and to_date are inclusive, so adjacent windows overlap on their shared boundary day if you set each window's end to the next window's start. A nightly job that runs 2023-01-01 to 2023-01-02, then 2023-01-02 to 2023-01-03, will return events from the second day twice. Build windows so that each end date is the day before the next start date, and keep the exact values in your run log so a rerun can reproduce the same slices.
For each project, write down the creation date, the timezone rule that follows from it and the window boundaries you used. Then check the edge days of every window: compare the event count for the last and first day of adjacent slices, and sample a few distinct_id and event time pairs from each boundary to confirm there are no duplicates or gaps. Confirm the current timezone behavior for your project with Mixpanel support or in the Raw Event Export API reference before you rely on it for a full-history extraction, since the rule shapes every reconciliation figure you report later.
The sequence for a complete Mixpanel export
The sequence turns a Mixpanel project into a verified, checksummed archive of raw events that you hold on your own storage, ready for import or analysis elsewhere. Each step leaves a record you can check before the source data is relied on.
Inventory projects and their residency region
Before any export runs, list every Mixpanel project that holds data you need, along with its project ID, its creation date and the region it lives in. Standard projects use the default API host, while EU and India residency projects must be queried through the data-eu or data-in hosts, so a request sent to the wrong host will not return the expected data. Record which projects hold events you are obligated to keep and which can be skipped. The finished inventory is a single table that every later step refers back to.
Confirm the timezone rule for each project
Mixpanel reads export dates as UTC for projects created after January 1, 2023, and in the project's own timezone for older projects. Check the creation date and the configured timezone for each project in your inventory, and write the rule next to it. Date windows that cross a day boundary will hold different events under each rule, so this check prevents silent gaps and overlaps at the edges of your windows. Ask Mixpanel support to confirm the rule for any project whose settings look unusual.
Create a service account with export access
Create a dedicated service account in Mixpanel for the export, scoped to the projects in your inventory with access to export raw data. Avoid using a personal login, so the export keeps working when staff change roles and so the account's activity is easy to audit. Store its credentials in your own secrets manager, not in scripts or shared notes. The output of this step is a working credential that returns a small test response for one project and one day.
Split history into date windows within rate limits
Divide each project's full history into date windows that your request plan can complete within the limits of 60 queries per hour, 3 queries per second and 100 concurrent queries. Requests that exceed these limits receive HTTP 429, so your script should pause and retry rather than fail the whole run. Keep a log of each window with its from_date, to_date and status, and remember that both dates are inclusive, so adjacent windows should not share a boundary day. The output is a complete calendar of windows for every project.
Request gzip output and store raw JSONL
Send each request with an Accept-Encoding header that asks for gzip, then write the response to storage as JSONL, where each line is one event with its properties, distinct_id and fire time. Keep the raw file exactly as received, without rewriting or reformatting it, so the archive reflects what Mixpanel returned. Use one file per project and window, named so that project, region and dates are visible in the path. The output is a directory of compressed raw files, one per window.
Write checksums and a manifest for every file
Compute a checksum for each file as soon as it is written and record it in a manifest with the project, region, timezone rule, window dates, row count and the time of the request. Store the manifest beside the data and protect both with the same access controls and backup policy. If a file is later found to be damaged or altered, the checksum and manifest show which window needs to be re-pulled. The output is a manifest that describes the whole archive and can be checked by anyone who has access.
Verify counts against Mixpanel reports
Compare the number of events in each window and each day of the archive with the counts shown in Mixpanel's own reports for the same project, timezone rule and dates. Investigate any mismatch before accepting the window, since differences often come from timezone settings or from windows that were pulled twice. Then sample distinct_id values and property fields from random lines in several files and confirm that they match what Mixpanel shows for the same users and events. The closed output is a signed-off verification log that names any windows you re-pulled.
What to plan before the Mixpanel contract renewal or termination
A Mixpanel exit is easier when the export is planned before the contract conversation starts. The cards below cover the decisions that shape the extraction: timing, what to keep, which regional host to call, what sits outside the raw event stream, and who approves the finished archive.
Set the export deadline early
Work backward from your notice date and the end of your current term. A full-history extraction runs through rate-limited API calls, so start early enough to re-run failed date windows. Confirm with Mixpanel in writing when access to the project and its raw data ends after termination, and whether any grace period applies. Treat the earliest date that ends access as the real deadline, not the date the contract lapses.
Decide what counts as the archive
Decide which raw events, which years and which projects belong in the historical archive. Raw events are the core asset, but you also need to decide whether you keep the derived reports, user profiles and property definitions. Write the scope down so the extraction, the storage budget and the sign-off all refer to the same dataset.
Confirm the residency host
Identify whether each project was served from the default region or from the EU or India hosts, and record the host each export must call. Exporting from the wrong host can return incomplete data or fail the residency commitment you made to your own regulators. Keep the EU or India copy in the same region as the source where your data rules require it.
Document saved reports and cohorts
Saved reports, dashboards, cohorts and funnels live in Mixpanel's interface, not in the raw event export. Inventory them with their definitions, filters and owners before access ends. For each one, decide whether it will be rebuilt in your new tool, kept as a written specification, or retired. Without this list, teams often discover missing metrics after the switch.
Agree who signs off the archive
Name the person who approves that the export is complete and correct before the Mixpanel project is closed. Typical checks include event counts per day against a sample from the Mixpanel interface, timezone handling, and confirmation that every requested window returned data. Record the approver, the date and the checksums in your records, so the archive can be shown to auditors or legal teams later.
Questions buyers ask before exporting Mixpanel data
How much does a full Mixpanel export cost and what drives it?
The export itself is priced through your Mixpanel contract, not through a per-export fee, so the cost you control is effort and infrastructure. The main drivers are total event volume, the number of projects you need to pull, how many days of history sit in each project, and how deeply you verify the output. Rate limits matter here: the raw export API allows 60 queries per hour, 3 per second and 100 concurrent queries, and returns HTTP 429 when exceeded, so a large history is pulled in many date-bounded requests over a longer window. Storage for compressed JSONL, and the compute to validate it, are recurring costs on your side. Ask Mixpanel in writing whether any export volume or API usage is billed to your account.
Can our team run a Mixpanel export without outside help?
Yes, a capable engineering team can run the export in-house, because the Raw Event Export API returns JSONL with one event per line, including its properties, distinct_id and fire time. The work is mostly scripting: requesting date ranges, respecting rate limits, handling retries on HTTP 429 responses, accepting gzip output and checking each file. Teams without someone comfortable with APIs, scheduled jobs and data validation usually find the verification step, not the download, is where time goes. Outside help is most useful for planning the date windows, designing the verification checks and setting up repeatable, documented runs. Scope any external engagement in writing before work starts.
What does our team need to provide for the export?
You need API credentials with access to the projects you want to export, a secure place to store the output, and a named owner for the decisions that cannot be automated. The owner should settle timezone handling, because Mixpanel reads export dates as UTC for projects created after January 1, 2023 and in the project's timezone for older projects. The same owner should confirm which regional endpoint applies: projects with EU or India residency use the data-eu or data-in hosts. Storage must match your data classification and residency rules, since exported files contain personal data if your events do. Keep credentials out of scripts and logs, and record who approved each export run.
How does export time grow as our history gets longer?
Export time grows roughly with the number of events and the number of request windows you need, and the rate limits set a ceiling on how fast you can move data. Because the API allows 3 queries per second and 60 per hour, a longer history means more windows and a longer elapsed run, even when the network is fast. Splitting history into smaller date ranges makes failures cheaper to retry, but it adds requests against the hourly cap. Both from_date and to_date are inclusive, so overlapping or missing boundaries will duplicate or drop a day. Test a single month first, measure the run, and extrapolate from that measured run rather than from assumptions.
Can exported Mixpanel JSONL be loaded into another platform?
JSONL is a portable format, so the files can be loaded into most analytics stores, but the target platform still needs its own import path and schema mapping. Mixpanel's export keeps the event name, properties, distinct_id and fire time, which map well to event-based tools. Check how the target handles identity, property types and timestamps before loading anything at scale. PostHog offers managed migrations that import history directly from Mixpanel using API credentials or from JSONL files in an S3 bucket, with at most one year of data per direct import job, and events are not deduplicated. Confirm those limits against PostHog's documentation before you plan the load.
What should we confirm with Mixpanel in writing before exporting?
Confirm the export terms, the current rate limits and whether they differ for your plan, and any charges tied to API use or data volume. Ask which regional host your project uses, and whether residency commitments cover the exported files once they leave Mixpanel. Get written confirmation of the retention window for the data you need, the export format and the timezone rule that applies to each project. Ask how to handle projects created before and after January 1, 2023, and whether any event history is excluded. Keep written answers with your migration record so auditors and your own team can trace each decision.
Where the exported data goes next
The JSONL files from the Raw Event Export API are the input to whatever comes next, whether that is a warehouse load, an internal analysis or a migration. If the next step is PostHog, you have two routes. PostHog's managed migrations can import historical events straight from Mixpanel using API credentials, or from JSONL files you place in an S3 bucket. The file route means your own export is the source of truth for that history, so the copy you hold locally or in your object store should be complete, checksummed and retained under your own policy before any import starts.
Plan the import around two constraints from PostHog's documentation. Each direct import job covers at most one year of data, so a multi-year history is split into several jobs, and events are not deduplicated. If you run overlapping date ranges, or re-run a failed job, the same events can be ingested twice. Keep your export date ranges non-overlapping, record the from_date and to_date used for each file, and confirm with PostHog how it handles jobs that partly fail. There is also no way to selectively delete event data once imported, so run a small test window first and check event counts and property names in a non-production project before loading the full history.
Confirm the commercial terms before you start the import. PostHog's migration documentation says historical imports carry no ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. Ask PostHog to confirm which plan applies to your event volume and region, and whether your Mixpanel project's residency (US, EU or India) matches the PostHog hosting region you choose. The detailed steps for the Mixpanel path, including credentials, identity mapping and SDK replacement, are covered in the migration pages under this hub.
How DeployOpen scopes and delivers an analytics data exit
DeployOpen treats a Mixpanel export as a fixed-scope engagement: the project, regions, date ranges and destination are agreed in writing before any extraction runs. The work covers planning the full-history pull through the Raw Event Export API, running it in your own infrastructure, and handing over validated files with documentation your team can reuse.
How we scope
- Confirm which Mixpanel projects, data residency region and date span the export must cover.
- Agree the project timezone setting for older projects so date boundaries match your reporting.
- Define the storage location, retention and access controls for exported JSONL files in your environment.
How we build
- Build a throttled extraction job that respects the hourly, per-second and concurrency limits and handles HTTP 429 responses.
- Run the extraction in one-year-or-smaller windows with gzip compression to keep transfers manageable.
- Validate row counts, event names and distinct_id coverage per window before accepting each batch.
How we hand over
- Deliver the exported files with a manifest of date windows, record counts and checksums.
- Provide a written runbook covering how to rerun, resume or extend an export without duplicate loads.
- Document schema notes for properties and fire times so downstream teams can load the data correctly.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing of the export pipeline are available as a retainer.
- Ask for a written quote that lists each scoped item, so cost follows from the agreed deliverables.
