n8n vs Zapier

n8n

Branching is genuinely there — switch nodes routing users by position and department, a ClickUp approval sub-workflow that waits, polls, sends reminder comments and times out, and a Gmail approve/reject/cancel step on a Google Form trigger — with test runs, mocked data and Git versioning plus a dev/prod environment split behind it. We found no public information on BPMN-style notation, substitutes and escalation chains, four-eyes multi-stage approvals or a built-in task inbox for participants, so I stop above the comfortable middle.

Zapier

The visual editor with paths, filters, looping and scheduling, plus Forms with conditional logic, covers branching automation well, and a documented REST API even builds workflows step by step up to a 25-step ceiling. We found no public information on approval steps assigned to roles, substitutes, deadlines or escalation chains, and nothing on keeping a running process on its original version while a business owner changes the definition — that is the part I need before letting a process owner near a live workflow.

n8n

The generic layer is exactly what I want to see: a documented HTTP Request node, an inbound Webhook node, JavaScript or Python code steps anywhere, a public API with key-based access to list workflows and credentials, and custom nodes — self-hosted only — beside Docker deployment, which puts the whole engine behind the firewall where Postgres and MySQL live. Named apps include Gmail, Microsoft Excel 365, Google Sheets and GitHub with per-node docs. We found no public information on connectors to SAP, DATEV or Dynamics, on SOAP or database connector action documentation, or on who maintains each connector, which is what I would need for the DACH back office.

Zapier

The webhook step, "Connect to any API without writing code", and a REST API for creating fully configured workflows give me the generic escape hatch, and custom integrations can be built in code on the CLI with full HTTP control including middleware. What holds it down: we found no public information on connectors to ERP or accounting systems common in DACH such as SAP or DATEV, on an on-premise agent that reaches internal databases and file shares without a hole in the firewall, or on SOAP and database steps, and connector maintenance ownership is not shown either way.

n8n

A failed step can be re-run on its own rather than replaying the whole run, automatic retries sit in the plan table, and a dedicated error workflow emails the failed workflow id, name and error source with a machine-readable error JSON — that is production-grade failure handling. Execution history is searchable by the data it contains, log retention and concurrency limits are published per plan, logs stream to Datadog, queue mode scales it, and LangSmith and OpenTelemetry tracing are documented for self-hosted. We found no public information on a status page or incident history, and whether retries are configurable with back-off is not described.

Zapier

Automatic retries on throttling, auth-refresh and retry on 401 responses, an execution history with per-request logs filterable by timeframe and user, email alerts on failure, and task limits per plan put solid operational basics on the page. We found no public information on replaying a failed run from the failing step — the documented behaviour is that the workflow pauses until manually re-enabled — nor on queueing and concurrency controls, a public status page or an uptime commitment.

n8n

Custom roles down to project viewers, SAML SSO and LDAP, an encrypted credential store with external secret store integration, execution data redaction and enforced 2FA — that is governance I can defend to an auditor. Audit logging exists, dev/prod environments publish through Git, SOC reports and technical and organisational measures sit in a public trust centre, and the privacy policy states plainly that Cloud records sessions but never credential values, which is what a works council asks first. We found no public information on SCIM provisioning or on exporting the audit trail.

Zapier

SAML-based SSO with SCIM provisioning, shared team folders with admin and collaborator roles, granular per-member permissions across 66,000+ triggers and actions, an admin view of every run with its owner, and shorter execution-data retention on Company and Enterprise are all evidenced. We found no public information on separate development, test and production environments with a publishing approval, external secret stores or published certifications; the SDK permission rules are explicitly guardrails on one's own credentials rather than an organisation-wide policy, which matters to a works council.

n8n

Workflows can genuinely leave: export to file from the admin panel, import into a self-hosted instance, versioned in Git, with the engine deployable by Docker on-prem and even air-gapped, and the source code public on GitHub. The cloud-to-self-hosted path is documented but manual only, and credentials cannot be exported from Cloud, so the secret layer has to be rebuilt by hand. We found no public information on documented system requirements or a documented route back from self-hosted to cloud.

Zapier

Zap workflows, Zap history and account data can be exported, integration code can live in the team's source control repository with conversion between the UI and CLI in both directions, and the terms allow export before deletion when switching providers. The engine itself is documented as operated from a cloud service located in the United States, and we found no public information on an EU region or a self-hosted edition, so the workflows run where the vendor runs them.

n8n

The contracting entity is verifiably German — n8n GmbH at Novalisstr. 10, Berlin, registered at Amtsgericht Charlottenburg with a German VAT number — with a pre-signed data processing agreement naming n8n as processor, and international transfers covered by SCCs and the Data Privacy Framework. The captured pages give me nothing on where cloud executions and their logs are stored, nor a subprocessor list with locations, and the self-hosted enterprise terms choose the law of England and Wales — so I can only credit what the entity and the agreement prove.

Zapier

A privacy policy and a data processing addendum exist, the GDPR roles are stated with the customer as data exporter and Zapier as data importer, and a DORA addendum is offered for EU financial entities — but the contracting entity is Zapier, Inc., a Delaware corporation, and the service is documented as operated from a cloud located in the United States. We found no public information on EU execution, an EU contracting entity or a published subprocessor list covering the processing chain; the third parties named on the privacy page are advertising and analytics providers.

n8n

Every self-serve tier is public with the billing unit honestly defined — a full workflow execution, not a step or a user — at 20€ /mo for 2.5k executions, 50€ /mo for 10k and 667€ /mo for 40k on the self-hosted-only Business plan, each billed annually, with unlimited users, every integration on all plans, a custom tier from 50,000 up to 500,000 executions on the monthly Pro-2 plan, fees stated exclusive of taxes and a 12-month enterprise term. A buyer can price a known run volume from the public pages alone. We found no public information on an overage price per execution beyond the allowance or the price of AI credits, and Enterprise is contact sales.

Zapier

The billing unit is unusually well defined: triggers, polling checks and a whole list of utility steps are documented as not counting as tasks, one MCP tool call uses two tasks, and tasks are shared across the account — a buyer can tell what a run will cost in units. What holds it back: Professional is quoted "Starting from $19.99 /month" and Team "Starting from $69 /month" without the per-tier task allowances, the pay-per-task overage is described only as a higher per-task rate than base subscription tasks without a per-unit price, Enterprise is "Contact for pricing", and taxes are the customer's responsibility on top.