What you can export from Amplitude and what you cannot
If a renewal, a pricing change or a data residency requirement means your raw event history has to leave Amplitude, the Export API and the Amazon S3 export are the documented paths for raw events. The Export API returns a ZIP archive of JSON files with one event object per line, and it selects events by server upload time rather than event time, so an hour of data can be spread across several files. Plan your file handling around that, and do not assume that a file maps neatly to a calendar hour.
The Export API has hard limits you need to design around. Requests over 4 GB are rejected with HTTP 400, each query covers at most 365 days, and the default limits of 4 concurrent requests or 360 requests per hour return HTTP 429 when exceeded. Amplitude recommends the Amazon S3 export when a single hour of data is larger than the 4 GB Export API limit. EU projects use the analytics.eu.amplitude.com endpoint, so confirm which region your project lives in before you script the pull. Check current limits with Amplitude, since your plan or contract may change them.
The facts available to us do not cover dashboards, saved charts, cohort definitions, chart configuration or user-level annotations. Do not assume these come out with the event archive. Ask Amplitude in writing which of these objects it can export, in what format, and whether any of them require a separate request. Record the answer as part of your migration inventory, because anything not in that list will need to be rebuilt or documented by hand.
Which data types Amplitude documents for export and their limits
This table sets out what the Amplitude Export API returns and the limits that shape each request, plus the EU endpoint and the S3 path for large hours. Read it as a list of constraints to plan around before you script an export. The sources we rely on document raw event data only, so confirm any other data types with Amplitude before you plan around them.
| Item | What Amplitude documents | What to plan for |
|---|---|---|
| Raw event data (Export API) | ZIP archive of JSON files with one event object per line | Parse line by line and expect each archive to hold many files |
| Selection key | Events are selected by server upload time, not event time | Match your date windows to upload time or late events may be missed |
| Hour spanning several files | One hour of data can be split across several files | Do not assume one file per hour when you build the loader |
| Maximum request size | Requests over 4 GB are rejected with HTTP 400 | Split large ranges into smaller windows or use the S3 export |
| Maximum window per query | At most 365 days per query | Chunk multi-year histories into successive requests |
| Default rate limits | 4 concurrent requests and 360 requests per hour; excess returns HTTP 429 | Add retries with backoff and confirm your project's limits with Amplitude |
| EU projects | Use the analytics.eu.amplitude.com endpoint | Point EU projects at this host and keep data handling aligned with your residency rules |
| Hours above 4 GB | Amplitude recommends its Amazon S3 export for these hours | Ask Amplitude to enable S3 delivery for high-volume projects |
| Other data types | Not listed in the sources used for this page | Confirm with Amplitude which other exports exist before you scope the work |
Export API or Amazon S3: choosing the path by volume
The Export API suits smaller projects where no single hour of data exceeds 4 GB. Amplitude's Export API returns a ZIP archive of JSON files with one event object per line, and requests are selected by server upload time rather than event time, so one hour can span several files. Each request is limited to 365 days, and requests above 4 GB return HTTP 400, so your script must split history into date ranges that fit.
- Credentials: Your team needs the project's API key and secret key, held in a secrets manager and never written into scripts or repositories.
- Date-range paging: Build a loop that walks forward in windows of at most 365 days, and check each window's size before treating it as complete.
- Rate limits: The default limits are 4 concurrent requests and 360 requests per hour. Exceeding them returns HTTP 429, so the loop needs backoff and a queue that runs requests one at a time.
- Storage: Plan a landing bucket or volume with enough room for the zipped output, and keep the raw archives unmodified so they can be checked later.
- Retry logic: Log each window and its result so a failed run can resume from the last completed window without re-downloading everything.
Confirm your largest hour with Amplitude before you commit to this path, because the 4 GB limit applies to a single hour, not to the whole export.
Amplitude recommends its Amazon S3 export when a single hour of data exceeds the 4 GB Export API limit. This path moves the work from paged HTTP requests to a bulk delivery into a bucket you control, which is the better fit when volume is high or when the export must run on a predictable schedule. Your team still owns the storage, the access policy and the downstream processing.
- AWS setup: You need an AWS account, a destination bucket and an IAM policy that lets Amplitude write to it, configured according to Amplitude's current instructions.
- Encryption and access: Decide how the bucket is encrypted and who can read it, and record those choices as part of your data handling documentation.
- Downstream processing: Plan how files will be loaded into a warehouse or analytics store, since the output is raw event data at a scale the Export API path does not handle.
- Cost components: Storage, egress and any processing compute are billed by your cloud provider and recur for as long as data is kept. Ask your provider and Amplitude to confirm current pricing for your region.
- Retention: Set lifecycle rules so archived exports move to cheaper storage or expire according to your retention policy.
Confirm with Amplitude that your project is eligible for the S3 export and which regional setup applies to your data.
Projects hosted in Amplitude's EU region must use the EU endpoint, analytics.eu.amplitude.com, for the Export API. Sending EU project requests to the default endpoint is a configuration error that will fail or return data from the wrong place, so the endpoint should be a named setting in your script rather than a hard-coded value. The same regional discipline applies when you choose a destination for exported files, because the archive is personal data that must remain under your residency rules.
- Endpoint setting: Store the regional base URL in configuration and document which environment uses which region.
- Residency of archives: Keep exported files in storage located in the region your data policy requires, and confirm that backups and replicas follow the same rule.
- Transfer assessment: If any stage of the pipeline sends data outside the EU, your legal team should review the transfer basis, including the European Commission's adequacy decision for the EU-US Data Privacy Framework, which covers only participating US companies.
- Access logging: Log who downloads or reads exported archives, since event data often contains identifiers.
- Test with one day: Run a small window against the EU endpoint first to confirm credentials and output format.
Check with your data protection officer which region and transfer mechanism apply before the first full export.
The practical decision is the size of your largest hour, not the size of your total history. A project with years of data can still use the Export API if its busiest hours stay below the limit, and a project with modest totals can still need S3 if traffic is concentrated in short bursts. Measure before you choose, and revisit the decision if traffic grows, because a bursty product launch can push one hour over the limit without any change in your average volume.
- Measure peak hours: Ask Amplitude or inspect a sample export to find the largest hour in your history, not the monthly average.
- Estimate by window: Compare the zipped size of representative hours against the 4 GB threshold.
- Plan for growth: Choose the path that still works at your expected peak for the next planning cycle.
- Hybrid approach: Some teams run the Export API for historical backfills and S3 for ongoing exports, which requires two sets of credentials and two runbooks.
- Operational ownership: Assign one owner for each path so failed runs are noticed and rerun.
Ask Amplitude to confirm the size of your heaviest hour in writing before you finalize the export design.
Either path shifts operational work onto your team. The Export API path puts most effort into the script, its scheduling and its failure handling, while the S3 path puts more effort into cloud access, storage governance and the processing pipeline. Assigning responsibilities before you start prevents exports from stalling after the first successful run, which is when most teams discover that nobody owns the schedule.
- Platform or data engineers: Build and maintain the script or pipeline, and handle rate-limit and retry behavior.
- Security team: Review how API secrets or IAM roles are created, rotated and revoked.
- Data owners: Confirm which event fields and user identifiers may be exported and for how long.
- Auditors and compliance leads: Request evidence of export runs, storage locations and access logs, which DeployOpen can help prepare as part of a compliance readiness engagement but which only independent auditors can attest to.
- Procurement: If you engage a partner, ask for the export design, runbook and handover documentation as written deliverables in a fixed scope.
Confirm who will run the export on its first anniversary, not only during the initial project.
What does not come out through the documented paths and how to work around it
The Export API returns raw events selected by upload time, within size, window and rate limits. Everything around those events, from charts and cohort definitions to governance settings and anything past retention, needs a separate plan. The cards below cover each gap and the workaround we would suggest before the export starts.
Dashboards, charts and cohort definitions
Raw event exports carry the events themselves, not the saved charts, dashboards, cohort logic or metric definitions built on top of them. Those objects live in Amplitude's interface and their export format is not covered by the supplied facts, so confirm with Amplitude what can be exported or documented for them. Before the cutover, screenshot or record each dashboard that a business owner relies on, list every cohort and the filter logic behind it, and rebuild the important ones in the target tool. Treat the rebuilt definitions as a new specification to review, not a copy.
Governance and configuration settings
Taxonomy rules, event and property definitions, permissions, and data governance settings such as blocked or hidden properties are configuration, not event data. A raw export will show what was sent, including events that governance later hid or that were never meant to be stored. Ask Amplitude which configuration objects, if any, can be retrieved programmatically, and export the tracking plan from your own documentation or source repository. Decide up front which properties may enter the new system, since personal data that was collected but later restricted must not be carried over by default.
Event-time boundaries shifted by upload time
The Export API selects events by server upload time, not by the time the event happened, and one hour of data can span several files. An event sent from a mobile device after being offline may land in a later export window than its event time suggests. This can cause events to be missed or counted twice when you pull windows by event date. Pull windows by upload time, record the window boundaries and file names in a manifest, and deduplicate on the event identifiers in the output before any count is compared with the source.
Events past retention or already deleted
Data that Amplitude no longer holds cannot be exported, and the supplied facts do not state Amplitude's retention periods, so confirm your plan's retention with Amplitude before the export starts. Events deleted by a user deletion request or a retention setting are also gone from the export. Establish the earliest event date you can recover, run the first full export before any scheduled deletion or plan change, and keep a written record of the date range you hold. In the target tool, mark the gap clearly so analysts do not read a short history as a drop in usage.
Oversized hours needing the S3 path
An Export API request over 4 GB fails with HTTP 400, and Amplitude recommends its Amazon S3 export when a single hour exceeds that limit. The S3 export is a different delivery mechanism with its own bucket access, file layout and setup steps, so it is not a retry of the same request with smaller parameters. Identify the high-volume hours from your own usage data, confirm S3 export access with Amplitude, and check that the destination bucket and its encryption and access policies meet your data protection rules before any file lands in it.
Rate-limited pulls and missing windows
The Export API returns HTTP 429 when more than 4 concurrent requests or 360 requests per hour are made under default limits. A large backfill run without throttling can therefore stop partway, leaving gaps that look complete at a glance. Build the pull job to retry 429 responses with a delay, log every window requested and every window confirmed, and reconcile the logged windows against the expected date range. Ask Amplitude whether your project has higher limits before you plan the run length.
The export sequence, from credentials to a verified archive
This sequence turns Amplitude's Export API into a complete, checksummed archive of raw events that you can verify against Amplitude before any source data is touched. Each step produces a record you can hand to the people who approve the migration.
Confirm plan and export entitlement
Before writing any code, confirm with the account owner that your Amplitude plan and user role allow the Export API, and check whether your organization also needs the Amazon S3 export. Ask Amplitude to confirm the default request limits for your project, since the documented defaults are 4 concurrent requests and 360 requests per hour. Record the project name, project ID, plan name and the name of the person who approved the export. Done means you have a written confirmation from your Amplitude admin that the export can run under your account.
Set the project and regional endpoint
Pick the endpoint that matches where the project's data is hosted. EU projects use the analytics.eu.amplitude.com endpoint, so calling the standard endpoint for an EU project is a common setup error. Store the API key and secret key in your secrets manager rather than in scripts or shared notes, and document which key belongs to which project. Done means a small test request with a one-hour window returns HTTP 200 and a ZIP file, and the test run is logged with the endpoint, project and timestamp.
Script date windows under the 4 GB cap
Build a job that splits the export into windows of no more than 365 days, which is the per-query maximum. Because the Export API rejects requests over 4 GB with HTTP 400, first check hourly volume with a smaller probe, and move any hour that exceeds the cap to the Amazon S3 export path that Amplitude recommends for it. Keep the window list in a version-controlled file so each run is repeatable. Done means you have a manifest listing every window, its start and end timestamps, and whether it will use the API or S3.
Respect concurrency and hourly limits with backoff
Run the windows with no more than 4 concurrent requests and stay under 360 requests per hour, unless Amplitude has confirmed higher limits for your project. When a response returns HTTP 429, wait and retry with increasing delays rather than retrying immediately, and log each retry. Record every window's status, byte size and attempt count in a run log. Done means every window in the manifest has a final successful response, and the log shows no window was skipped or silently abandoned.
Store ZIP archives unchanged
Save each response exactly as received, as a ZIP archive, in write-once or versioned storage inside your own infrastructure. Do not unzip, re-compress, rename content or edit the JSON during download, because the archive is your evidence of what Amplitude returned. Note that the files are selected by server upload time rather than event time, and that one hour can span several files, so the archive will not map neatly to calendar hours. Done means each stored file has a recorded name, size, window identifier and SHA-256 checksum computed at download.
Verify file counts, event counts and checksums
Confirm that the number of ZIP files matches the number of responses in the run log, and recompute every checksum from the stored files. Unzip each archive in a scratch location and count the JSON lines, where each line is one event object, then compare the totals per window with the counts in your run log and any count Amplitude provides for the same window. Investigate any mismatch before proceeding, and treat overlapping windows as a reason to deduplicate, not to discard data. Done means a signed verification report lists, for each window, the file count, event count and checksum match.
Hold source data until sign-off
Keep the Amplitude project and its data in place until the verification report has been reviewed by the data owner and the people responsible for retention and records. Ask the data owner to confirm in writing which records, if any, must be kept outside the archive, and confirm your own legal and contractual retention obligations before any deletion request is made. Store the archive, manifest, run log and verification report together under access controls. Done means a named approver has accepted the verification report and the archive location is recorded in your migration plan.
How to prove the export is complete before you cancel
Before you cancel Amplitude, the export is only finished when you can show, window by window, that the archive you hold matches what Amplitude recorded. Build a manifest that lists every Export API request as a row: the start and end timestamps, the EU or US endpoint used, the number of files returned, the byte size of each ZIP, the time the request ran, and the checksum of each file. Keep the raw archive, unmodified, as the system of record, and write all transformations, including loading into PostHog or a warehouse, as separate derived copies. That separation lets you rerun a check later without depending on a tool that may have changed.
The main reconciliation risk comes from how the Export API selects data. Amplitude selects events by server upload time rather than event time, and an hour can span several files. An event generated at 14:55 but uploaded at 15:10 belongs to the 15:00 window, so a count taken by event timestamp will not match the archive. Compare hourly counts from the raw files against Amplitude's own charts for the same windows, and expect small differences where late uploads arrived after you pulled a window. Decide in advance whether you will re-export a window after a set grace period, or accept late arrivals as a documented residual. Confirm the grace period with your own compliance owner, because it defines what you can later claim about completeness.
Sample individual events as well as totals. Pick a fixed number of events per window, chosen randomly, and confirm that their event type, user and device identifiers, and properties are present in the archive. Repeat the check for the windows with the highest volume and for any release date when tracking plans changed. Record the outcome in the manifest, sign it off, and store it next to the archive. Do not cancel the Amplitude contract until a second person has reviewed the manifest and every window is either reconciled or explicitly accepted as an exception.
Common questions about exporting from Amplitude
How much does exporting data from Amplitude cost in effort?
The effort depends mostly on event volume, the number of Amplitude projects and whether your team can script the Export API. A small project with a few months of history is a short job. Large volumes add scripting, retries, storage and validation work. The cost components are the people who write and test the export, the storage and compute you run to hold the files, and any ongoing review. Ask for a quote that splits these into one-time and recurring items and names the event volume and project count it assumes.
How long does an Amplitude data export take?
Duration depends on how much history you pull and how close you run to the export limits. The Export API rejects requests over 4 GB and allows at most 365 days per query, so longer histories are split into multiple requests. It also returns HTTP 429 when the default limits of 4 concurrent requests or 360 requests per hour are exceeded, so your export runs more slowly than a single bulk download. Ask the provider to show the request plan, the number of windows and the throttling they expect before agreeing a timeline.
Which limits in the Amplitude Export API affect large exports?
Three limits shape the work. Requests over 4 GB fail with HTTP 400, each query covers at most 365 days, and the default concurrency and hourly request caps return HTTP 429. The Export API also selects events by server upload time rather than event time, and one hour of data can span several files. Amplitude recommends its Amazon S3 export when a single hour exceeds the 4 GB limit. Confirm your largest hour of data before choosing between the API and S3.
What does the work need from our team?
You need an Amplitude user with access to export data for the relevant projects, a storage location with enough capacity for the zipped JSON files, and a named owner who can approve scope and sign off on the result. Your security team should confirm where exported files may be kept and who can read them, since raw events can contain personal data. Ask the provider which access, network paths and storage buckets they will require and how credentials will be stored and rotated.
Can our in-house team export Amplitude data without outside help?
Yes, if your engineers are comfortable scripting against the Export API and handling rate limits, retries and file validation. The API returns a ZIP archive of JSON files with one event object per line, so parsing and deduplicating the output is straightforward for an experienced team. The harder parts are planning windows around the 365-day and 4 GB limits, checking completeness and keeping the job running reliably over many hours. Estimate that effort honestly against your team's current workload before deciding.
Does EU data residency change how we export from Amplitude?
It can. EU projects use the analytics.eu.amplitude.com endpoint, so the export must target that host rather than the default one. Your exported files then need storage in an approved location, with access controls and a documented retention period. Your data protection team should confirm the lawful basis for the export and any transfer or processing agreement that applies to the destination. Share the project's region and storage plan early, because it can change the architecture and the approvals needed.
What would change the scope of an export engagement?
Four factors usually change the scope: a much larger history than planned, a single hour of data above the 4 GB limit that moves the work to the Amazon S3 export, a change in region such as EU residency, and the need to load the data into a new platform rather than just archive it. Each adds scripting, testing or approvals. DeployOpen plans, implements and documents this work as a fixed scope agreed in writing before it starts, so ask for the assumptions to be listed in the quote.
What to plan before the Amplitude contract renewal or termination
Exporting from Amplitude is only one part of a renewal or exit. The decisions below connect the export window, what happens to data at termination, and the history you choose to keep. Confirm each with Amplitude and your own records before the notice date passes.
Set the export window before notice
Work backward from your notice date and the date your data access ends. Export API requests cover at most 365 days each, and a single hour can span several files, so plan batches by time range and run them well ahead of the deadline. Confirm your notice period and access cutoff in writing, because the facts available here do not state them.
Confirm whether data is deleted at termination
Ask Amplitude, in writing, whether project data is deleted when the contract ends, how long any deletion takes, and whether a grace period applies. Google's Universal Analytics shutdown shows how quickly unexported analytics history can disappear once access ends, so treat the export as the only copy you can rely on until you verify otherwise.
Freeze SDK and tracking changes
Decide a change freeze window for tracking plans, event names and SDK upgrades while the export runs. Changing event schemas mid-export makes the raw files harder to map and complicates later comparison with the new platform. Record the tracking plan version that was live for each period so that exported events can be interpreted correctly.
Decide what to migrate and what to archive
Separate history you will load into the new platform from history you only need to keep for reference. Direct historical imports from Amplitude cover at most one year per job, and PostHog's documentation says there is no way to selectively delete imported event data. Choose the migration scope before importing, not after.
Retain the archive under your own policy
Store the exported JSON files in storage you control, with access controls, encryption and a retention period set by your records policy and legal obligations. For EU projects, confirm the export endpoint and storage location match your data residency commitments. Document who can read the archive and when it will be deleted.
Confirm contractual terms with Amplitude
Review the renewal or termination clauses for notice periods, data return or deletion obligations, export rights, and fees for extended access. The supplied facts do not give these dates or terms, so request them from your Amplitude account team and keep the answers with the contract file. Involve legal and procurement before the notice date.
Where a PostHog migration fits after the export
The export is the archive of record. Once raw events are in a ZIP of JSON files on your own storage, you hold a copy that does not depend on Amplitude's query limits, plan terms or retention settings. A managed migration to PostHog is a separate project with its own decisions. PostHog's managed migrations can import historical events directly from Amplitude using API credentials, but each direct import job covers at most one year of data, and events are not deduplicated. Before you start, confirm the Amplitude project, date range and event set you need, and confirm that the export for those same windows has been checked for completeness.
Verify the export first. Compare event counts per day or per hour against what Amplitude reports for the same windows, check that the files open and parse, and confirm that the endpoint and region match your project (the EU endpoint is a common source of empty pulls). Keep a record of the checks, because the export is the copy you will fall back to if an import is interrupted or needs repeating. Note that the migration path is not a substitute for the export: the direct import reads from Amplitude again, while the archive stays under your control even if Amplitude access changes.
Plan the migration with its cost and risk in view. Import features require a paid product analytics plan on PostHog, and there is no way to selectively delete event data once it has been imported, so a wrong date range or duplicate job stays in the project. Decide early how you will avoid duplicate imports and how you will remap event names. The sibling pages cover the steps in detail: Migrate from Amplitude to PostHog describes the import itself, and the Amplitude cost and comparison pages in this hub set out plan limits and what each option costs over time. Ask PostHog and your own team to confirm current plan terms before committing to a migration.
How DeployOpen scopes and delivers an Amplitude data export
DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an Amplitude export, we start from a written scope that defines which projects, date ranges and destinations are in play, then build and document the extraction path in your environment.
How we scope
- Inventory which Amplitude projects, event types and date ranges must leave the platform.
- Confirm whether each project uses the US or EU endpoint before any request is built.
- Measure hourly volume against the 4 GB Export API limit to choose between the API and S3 export.
How we build
- Write the extraction job, including handling of ZIP archives of one-event-per-line JSON files.
- Set request pacing around the 4 concurrent request and 360 requests per hour default limits.
- Load exported files into your chosen storage with checksums and a record of each completed window.
How we hand over
- Document the export procedure, retry behavior and how to resume after a rate limit response.
- Provide a reconciliation report comparing exported event counts against Amplitude's own figures.
- Deliver runbooks and access controls so your team can repeat or audit the export independently.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and re-runs for new data windows are available as a retainer.
- Confirm with us during scoping which post-handover support level fits your team's operating model.
