How to export your data from Zapier

How to export your data from Zapier: what you can take out and what you cannot

If you are facing a Zapier renewal or planning a move off the platform, the first answer you need is this: Zap workflows can be exported as JSON files on Team and Enterprise plans, and that file documents your workflows but does not carry your app credentials or your run history. Free and Professional accounts cannot use the export at all, so confirm your plan before you plan the rest of the exercise. Zapier's help center is the only source we rely on for the export path, and its article on importing and exporting Zap workflows is the document to check against your own account before anyone starts work.

Two roles matter here. Individual users on Team and Enterprise plans can export their own Zaps from Settings, then Security and data, then Data management. Account owners and super admins can export the Zaps of every user in the account, and Zapier delivers that bundle as a JSON file to the account email. Confirm internally who holds those roles, because a migration that depends on one person's login can stall when that person leaves the company. Zapier also warns that large Zaps and accounts with many workflows take longer to export, so schedule the export early instead of on the day the contract ends.

Treat the JSON as an inventory for rebuilding, not as a file that n8n or Activepieces will import. It lists what each workflow does, which is the starting point for mapping steps to the target platform. Credentials, connection authorizations and historical run data are outside it, so you must recreate connections and decide what to keep from past runs. Once a Zap is re-imported into Zapier, it lands in a dated folder and must be turned on with its app connections checked, so use the same checklist for any round trip. Ask Zapier to confirm in writing what the export contains for your account before you rely on it as your only record.

What Zapier exports, by data type, method and format

This table compares the two Zapier export paths, individual user exports and admin exports of all users' Zaps, along with the import path and format. Read it to see who can run each export, where the menu sits, how the file arrives and what to expect for large accounts before you plan a move.

Export path	Who can run it	Plan and delivery	Notes before you move
Individual user Zap export	Each user, for their own Zaps	Team and Enterprise plans only, downloaded as a JSON file from Settings, Security and data, Data management	Free and Professional accounts cannot export. Confirm each user has exported every Zap they own.
Admin export of all users' Zaps	Account owners and super admins	Team and Enterprise plans only, sent as a JSON file to the account email from Settings, Security and data	Gives one file set for the whole account. Check the email address on the account receives it.
Export format	Applies to both paths	JSON is the only documented export format	Treat the file as a readable inventory of triggers, actions and settings, not a file another tool imports directly.
Large Zaps and large accounts	Applies to both paths	Zapier warns that export takes longer for large Zaps or accounts with many workflows	Start exports early in the project so delivery delays do not hold up the rebuild.
Import back into Zapier	Account users on Team and Enterprise	Imported Zaps land in a dated folder and must be turned on and have app connections checked	Useful for restoring or copying within Zapier. It is not a route into n8n or Activepieces.

What does not come out of Zapier in the documented export

The documented export gives you Zap workflow definitions as JSON, and nothing else is guaranteed to travel with them. Credentials, run history and table data each need a separate plan before you cancel. Confirm the scope of each gap with Zapier before you rely on the file as your only record.

App connection credentials

The JSON file describes the steps of each Zap but does not carry the authorized connections that let those steps reach Slack, Google, CRMs or databases. Plan to re-authorize every app in the new platform, using service accounts where you can, so that tokens are issued to the new system and not copied out of Zapier. After import into Zapier, connections must also be checked, so build a list of every app and owner before you start. Confirm with Zapier whether any connection secrets can be exported at all.

Run history and task logs

Past runs, their inputs, outputs and error messages are not part of the workflow definition. If your audit or incident process depends on them, export or copy the records you need from Zapier's run history and from your downstream systems before you cancel the plan. Record the date range you keep and where it is stored. The new platform starts its own execution history from the first run, so there is no continuous record across the move.

Zapier Tables data

Records stored in Zapier Tables used as lookup lists, queues or small datasets are not part of a Zap export. A Zap that reads a table will import as a workflow step pointing at a table that no longer exists in the account. Extract the records through a separate export or API read, check row counts against the source, and move them to the new database before you switch workflows on. This is also where a self-hosted database such as Baserow can take over the data.

Folder placement and activation state

Imported workflows land in a dated folder and are not turned on automatically, so their organization and status do not carry over as operational state. Note which Zaps are active, paused or owned by which user in your inventory, because the JSON file alone will not tell you. Activation in the new tool is a decision you make per workflow, not something the export preserves.

Webhook endpoints and trigger identifiers

Zapier-hosted webhook URLs and trigger subscriptions belong to Zapier, so external senders that post to them will stop reaching your flows after cutover. List every inbound webhook and the system that calls it, then point those senders at the new endpoint and test each one. Plan for a period when old and new endpoints both receive events, and confirm with Zapier how long its hosted endpoints keep responding after you cancel.

Why the Zap JSON is an inventory for rebuilding, not an import file for n8n

The Zap JSON file is a record you review and rebuild from, not a workflow another platform will run. Zapier's export captures each Zap's steps and settings so you can see what every trigger and action does, which apps it touches and how data moves between steps. n8n and Activepieces do not import Zapier JSON as a working workflow, so treat the file as a specification. Open it, list each Zap, and write down its trigger, each action, filters, formatter steps, paths and the fields mapped between them before you build anything in the target tool.

Once you have that list, map every Zapier trigger and action to a node in n8n or a piece in Activepieces. Where a counterpart exists, note the operation name, the required inputs and the authentication type, since those are what you will reconfigure. Where none exists, record it as a gap and decide whether to use a generic HTTP or webhook step, a code step or a custom piece. Mapping by hand also exposes Zaps that depend on Zapier-specific behavior, such as deduplication, looping or built-in storage, which need a deliberate replacement rather than a copy.

Zapier's own import shows how tightly the file is tied to its model. Zaps imported back into Zapier land in a dated folder and must be turned on and have their app connections checked, according to Zapier's help center. Connections, account identifiers and secrets do not travel with the file, so you should expect to recreate every credential and webhook in the new platform. Confirm with your Zapier admin which Zaps are still live, who owns each one and which connections are shared, because the export gives you the logic but not the operational state.

Run a complete Zapier export in the order that keeps you covered

This sequence confirms you can export, collects every Zap from every owner, and produces a verified inventory of JSON files and connection notes that you can use to rebuild workflows in another tool.

Confirm the plan and your role
Check that the account is on a Team or Enterprise plan, because Zapier documents JSON import and export only for those plans. Free and Professional accounts cannot use it. Then confirm who will run the export. Users can export their own Zaps from Settings, then Security and data, then Data management. Account owners and super admins can export every user's Zaps. Write down the name of the person who holds that role, so the export does not stall on a missing permission. Done when you have confirmed the plan in the billing settings and the role of the exporting person.
Inventory which users own Zaps
Before exporting, list every user who has built Zaps in the account. Ask each team lead which Zaps they own, including Zaps that run for shared business processes but were created by someone who has since left the company. This list tells you whose Zaps the admin export must cover and where personal exports could leave gaps. Keep the list in a spreadsheet or ticket. Done when every owner you found has a row, and each row has a note on whether that person still works for the organization.
Run individual and admin exports
Run an admin export that covers all users, since account owners and super admins can export every user's Zap workflows in one request. Use individual exports from Settings for any Zap that needs a separate copy, such as a workflow an owner wants preserved before a change. Zapier warns that large Zaps and accounts with many workflows take longer to export, so start the request early in the working day and avoid editing Zaps while it runs. Done when you have submitted each request and recorded the time and the requester in your log.
Wait for the export email and download the files
Zapier delivers admin exports by email to the account email address, so the mailbox owner must be available to download the file. Do not assume a delivery has finished because the request was accepted. Check the account inbox, confirm that the attachment or link is a JSON file, and download it from a managed device. Done when every requested export has arrived and you have downloaded each JSON file without changing its contents.
Store the JSON files with access controls
Each export contains workflow logic, and some Zaps may reference sensitive data in field mappings, so treat the files as confidential. Store them in a restricted location such as an access-controlled folder in your document system or a secured repository, with access limited to the migration team and the security owner. Record where each file is kept and who can read it. Done when the files are in that location, permissions are set, and a short access list is recorded.
List each Zap with its trigger, actions, status and apps
Open each JSON file and build a table with one row per Zap. Record the Zap name, owner, trigger app and event, each action app and event, whether the Zap was on or off when exported, and the apps it connects to. This table is your rebuild inventory. The JSON is an inventory for rebuilding, not something a target tool imports directly, so the table is the working document your engineers will follow. Done when every Zap in the files has a complete row and the table has been reviewed by the Zap owners.
Verify the Zap count against the files
Compare the number of Zaps shown in Zapier with the number of Zap workflows in your files and your table. Count per owner as well as in total, so you can spot a user whose Zaps were missed. Ask the account owner to confirm the total in the Zapier interface. Investigate any difference before continuing, including Zaps that were off, Zaps owned by departed users and Zaps in folders that may be filtered. Done when the counts match for each owner, or every gap has a documented reason and an owner who accepts it.
Record connections and webhook URLs to recreate
The export describes workflow logic, but app connections are not a substitute for working credentials in the new platform. Record each app connection used by each Zap, the account it authenticates to, and the owner who can re-authorize it. Also list every webhook URL and trigger endpoint that other systems call, because those callers must be pointed to the new endpoint. Zapier documents that imported Zaps must be turned on and have app connections checked, so plan that check into the rebuild. Done when you have a connection register and a webhook register, each with an owner for every entry.

Who exports what: individual users, super admins and account owners

A regular member on a Team or Enterprise plan can export the Zap workflows they own as JSON files from Settings, then Security and data, then Data management. This route only covers that individual's workflows. Zaps built by colleagues, shared automations owned by someone else, or workflows that a departed employee created will not appear in the file, so this path is useful for a personal inventory but rarely for a company migration.

Scope of the file: Only the Zaps the signed-in user can export, not the account as a whole.
Delivery: The export is sent as a JSON file to the account email, so the user must be able to reach that mailbox.
Large accounts: Zapier warns that large Zaps or many workflows take longer to export, so allow time before the migration window opens.
Ownership gaps: Ask the account owner which Zaps belong to other people and who will export them.
Plan check: Confirm the plan is Team or Enterprise before assuming the menu exists.

Before you rely on a personal export, ask the owner for a list of every user who builds Zaps and compare it with the set of files you received.

What to plan before the Zapier contract ends

A Zapier export is only one step in leaving. The items below cover the contract, timing, target platform, parallel running, data outside the Zap JSON and ownership, so the export file becomes a working inventory rather than a last-minute download.

Confirm the exit date and notice terms

Read the notice period, renewal terms and any data retention or deletion clause in your Zapier agreement before setting a cutover date. Procurement or legal should confirm when access ends, whether account data is removed after termination and how long you have to request an export. Treat the contract as the deadline, not the date you finish rebuilding.

Schedule exports well ahead

Zapier warns that large Zaps and accounts with many workflows take longer to export, so start early and run a full export while your plan still allows it. Only Team and Enterprise plans can export JSON, so confirm your plan tier now. Keep each file dated and store it in a location your migration team controls.

Choose the target and its license

Pick the replacement platform before rebuilding starts, because its license determines what you can do with it. n8n uses the Sustainable Use License, which is source-available and limited to internal business or non-commercial use. Activepieces' Community edition is MIT licensed. Have legal confirm that the license fits how your company will use the platform.

Plan parallel running

Keep critical Zaps running in Zapier until the rebuilt workflow has processed real inputs and matched its output. Run both versions side by side for a defined period, compare results and disable the Zapier original only after the new workflow is verified. Avoid double triggers by checking webhooks and polling sources before each switch.

Collect data outside the Zap JSON

The JSON export describes steps, settings and mapped values, but it does not carry everything you need. Gather Zap history and run logs you must keep, Zapier Tables contents, lookup lists, webhook URLs, schedules and any notes on why each workflow exists. Export or record these separately before the account closes.

Assign owners for credentials and retirement

Name one owner for recreating each app connection in the new platform, since connections are not carried over from the export. Give another owner responsibility for turning off Zaps, revoking Zapier access, removing stored secrets and confirming deletion. Record who signed off on each workflow so that auditors and business owners can trace every cutover decision.

Questions teams ask before exporting from Zapier

Can a Free or Professional Zapier account export its Zaps?

No. Zapier documents JSON import and export of Zap workflows only on Team and Enterprise plans, so Free and Professional accounts cannot use this path. If you are on one of those plans, the practical options are to upgrade for the duration of the export or to document each Zap by hand from the Zapier editor. Confirm current plan entitlements with Zapier before you plan the work, because plan names and feature access can change. Either way, the JSON file is only an inventory, so the rebuild effort is the same whichever way you collect the definitions.

How long does a Zapier export take?

Zapier does not publish a fixed export time in the documentation supplied for this page, and it warns that large Zaps and accounts with many workflows take longer to export. Ask Zapier support for the expected timing for your account size before you schedule the export. Plan around that answer, not a generic estimate, and leave time to check the file once it arrives. Admin exports are delivered by email, so confirm which mailbox receives the file and that it is not blocked by your mail gateway.

Can I import a Zapier JSON export into n8n or Activepieces?

No, not as a working flow. The JSON describes your Zaps so you can see their triggers, actions and field mappings, but it is not a import format for n8n or Activepieces. Treat the file as an inventory: each Zap becomes a workflow you design, build and test in the target tool. Credentials and app connections do not transfer, so every connection must be created again in the new platform. Plan the rebuild per Zap, starting with the ones that matter most to the business.

What does the migration need from my team?

At minimum you need three roles. An owner keeps the inventory, tracks which Zaps are in scope and signs off on cutover. An administrator with Zapier account owner or super admin rights runs the admin export across all users, since individual members can only export their own Zaps. Engineers or automation specialists rebuild and test each workflow in the target platform. Add a business reviewer for workflows that touch finance, customer or regulated data, because they must confirm the rebuilt logic matches what the Zap did.

Can we export and rebuild our Zaps ourselves?

Yes, for small inventories with a few Zaps, standard connectors and a team that already knows the target platform. Your costs are mostly staff time for inventory, rebuild and testing, plus the hosting you run yourself. Effort rises with the number of Zaps, the share that use connectors the target platform lacks or requires custom code for, and how many run against production data. Your team is also responsible for the ongoing patching, backup and access control of the self-hosted platform once it is live.

What should a quote from an implementation partner cover?

A written quote should follow a written scope and list each deliverable. Ask for the inventory review, the Zap-by-Zap rebuild plan, the number of workflows in scope, connector gap analysis, credential and webhook recreation, test cases and sign-off, production cutover and rollback steps, documentation, and handover training. Ask what is excluded, such as custom connectors, data migration of run history, or post-go-live support, and whether ongoing support is offered as a separate retainer. DeployOpen does not publish a price list, and a quote follows from the agreed scope.

Does the export file contain credentials I need to rotate?

Plan as if it does not, but verify before you rely on that. Zapier's documentation says that after an import, app connections must be checked, which means connections are not restored automatically. Still, the file describes how each Zap is configured, including field mappings and any values typed into steps, so treat it as confidential business material. Store it in an access-controlled location, limit who can open it, and remove copies once the rebuild is finished. Review any hard-coded values in the export for secrets before you move them into the new platform.

What should we do with Zaps that call systems behind a firewall?

List them as a separate group in the inventory, because they often depend on the hosted service being able to reach private systems. Self-hosting the new platform inside your network can remove that dependency, since the workflow engine runs where the systems are. Confirm network paths, service accounts and firewall rules for each internal system before you rebuild those flows. Test them in a non-production environment first, then cut over one group at a time so you can roll back a single workflow without affecting the rest.

What the work needs from your team before you start

Before anyone exports a Zap, confirm who can actually do it. Full exports across the account are limited to account owners and super admins, who receive the JSON file by email from Settings, Security and data. Per-user exports are a narrower path that Team and Enterprise members can run on their own Zaps. Name one owner for the account-wide export, and confirm that person can see every user's workflows and that your plan is Team or Enterprise, since Free and Professional accounts cannot use the feature at all. If you hold neither role, your admin is the first dependency on the critical path. The export file tells you what exists, not who depends on it. Ask the people who run the business processes to name the Zaps that are business-critical, including those that run overnight, feed finance or support, or touch regulated data. App owners are the second group you need. After a rebuild, connections must be re-authorized under accounts your organization controls, and an app owner or the account holder for each SaaS tool must approve that. Plan those sign-offs early, because a Zap cannot be verified until its connections work again.

The effort grows with the number of Zaps, the number of custom code steps and the number of connector gaps. A small set of simple trigger-and-action Zaps is mostly inventory and credential work. Each code step must be read, translated and tested by someone who can write JavaScript or Python, and each app with no matching connector needs either an HTTP node or a custom component, which adds design and security review. Count these three factors for your own estimate, and ask whether each one is a quote line item. You can decide which parts to do in-house. Teams often keep inventory, owner sign-off and credential handling internally, because they hold the business knowledge and the access, and hand off the connector mapping, code translation and hardening to an implementation partner. DeployOpen plans and implements these phases under a written scope, so the list of Zaps, owners and open connector questions is the input that makes that scope precise. Decide the split before you request a quote.

How DeployOpen scopes and supports an exit from Zapier

Exporting Zap JSON is the start of an exit, not the finish. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and the work below connects the export to a rebuilt, tested and supported automation estate.

Inventory review as a defined deliverable

Zapier's JSON export gives you a file per Zap, but it does not tell you which Zaps still matter, who owns them or which ones feed other systems. A written inventory review can classify each workflow by owner, trigger, connected apps, data classes and business criticality, so the rebuild list is agreed before any n8n or Activepieces flow is built. Ask for the classification fields and the sign-off step in the scope.

Credential and connection recreation

Exported JSON describes steps and mapped values but does not carry working app connections. Each connection must be recreated in the target platform under a service account or named owner, and the owners of every credential recorded. Plan for a credential register that lists the app, the account used, the scopes granted and the person accountable, so no Zap is reactivated with a connection nobody can explain.

Target platform and license fit

Choosing between n8n and Activepieces depends on license terms as much as features. n8n is under the Sustainable Use License, while Activepieces Community is MIT licensed with its enterprise directories under a commercial license. DeployOpen can document which edition, license and feature set each workflow needs, so that your legal and procurement teams review a written decision rather than an assumption.

Hosting, hardening and runtime architecture

Self-hosted runtimes need a deliberate design: Docker Compose or Kubernetes, PostgreSQL and Redis where the platform requires them, the encryption key handling for credentials, and network paths to internal systems. DeployOpen can implement the runtime inside your cloud account, data center or air-gapped network, harden it and document the configuration so your platform team can operate it.

Testing before reactivation

Importing a Zap does not prove it behaves the same way. Imported Zaps must be reactivated and their connections checked, and the rebuilt workflows need test cases for error paths, retries, rate limits and webhook signatures. DeployOpen can run security and functional testing against the rebuilt flows and record results per workflow, so cutover decisions rest on evidence.

Documentation, handover and ongoing support

Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Handover can include runbooks, a workflow register, backup procedures and upgrade steps. Where your team needs continued help with upgrades, monitoring or new workflows, support is available as a retainer. Quotes follow from the written scope, and DeployOpen does not publish a price list, so ask for the scope and deliverables in writing first.

How to export your data from Zapier