Zapier, Make and choosing an automation platform

Job ads for automation roles name Zapier, Make and n8n in one breath as if they were interchangeable. They are not, and being able to say how they differ — by execution model, by pricing unit, by what happens when a step fails — is the whole signal in this question.

n8n’s own mechanics are in n8n and low-code automation. This note is the comparison and the decision.

The three, by shape

The billing unit is the design constraint, and it is the detail candidates miss. Zapier charges per task — roughly, per action step that runs — so a workflow that loops over 200 rows costs 200 tasks. Make charges per operation, which is finer-grained still: each module call counts, including iterator cycles. n8n self-hosted charges nothing per step, which is why it wins on high-volume loops and why n8n Cloud prices by execution rather than by step.

The practical consequence: a design that is cheap in n8n can be ruinous in Zapier. Fan-out over a list is the usual trap. If you must loop in Zapier, batch server-side first and hand it one item.

Where each genuinely wins

Zapier — breadth and non-technical ownership. The connector catalogue is the largest by a wide margin, and the linear editor is legible to someone in Finance who will maintain it. Choose it when the integration exists, the volume is low, and the owner is not an engineer.

Make — data shape. Its iterators, aggregators, array/text functions and router branching handle transformation that Zapier needs a code step for. The visual graph shows parallel branches honestly rather than flattening them. Choose it when the work is reshaping data between two APIs.

n8n — control and volume. Self-hostable (so data never leaves your infrastructure — often the deciding factor in regulated or NDA-bound work), arbitrary JavaScript/Python in code nodes, no per-step billing, and workflows exportable as JSON you can put in git. Choose it when volume is high, data is sensitive, or you need real code in the middle.

Error handling is where they diverge most

This is the question behind “have you actually run one in production”.

• Zapier auto-replays a failed task for a period and emails the owner. There is a per-Zap error queue, but recovery is largely manual and per-run.
• Make has explicit error-handler routes per module — you attach a path for the failure case, with directives like resume, break or rollback — plus incomplete-execution storage you can retry. The most expressive of the three.
• n8n gives you an error workflow: a separate workflow that runs on failure and receives the execution context, which you can wire to Slack, a ticket, or a retry. Plus per-node retry settings and continueOnFail.

The senior framing: all three retry the step; none of them make your downstream idempotent. A retried “create invoice” creates two invoices unless the target API takes an idempotency key or you check first. That is your problem regardless of platform — see Idempotency.

Whatever the canvas offers, the key has to come from something stable in the trigger — never from the run, which changes on every retry:

// n8n Code node / Make custom JS. The trigger's event id is stable
// across retries; $execution.id and Date.now() are not.
const key = `invoice:${$json.event_id}`;
return [{ json: { ...$json, idempotency_key: key } }];

The part nobody mentions: these are untested production code

A workflow is JSON in a vendor’s database. That means:

• No diff, no review, no blame. Someone edits a pricing rule in the canvas and there is no record of what it was before.
• No unit tests. You test by running it against real systems.
• No environments. Staging vs production means duplicating the workflow and keeping two copies in sync by hand.
• Silent failure is normal. A disabled Zap or an expired OAuth connection stops moving data and nothing alerts unless you built the alert.

Mitigations worth naming, because they are what separates a hobbyist from someone who has run this: export workflows to git on a schedule (n8n makes this easy, the SaaS tools need API calls), put business rules behind your own API so the workflow only calls it, add a heartbeat that alerts when a workflow has not run in N hours, and keep credentials in the platform’s vault rather than pasted into fields.

# The pattern that makes low-code safe: the platform does glue,
# your service owns the rule. One HTTP node, versioned logic.
@router.post("/internal/price-quote")
def price_quote(req: QuoteRequest) -> Quote:
    """Called by an n8n/Make/Zapier HTTP step. Tested, reviewed, in git."""
    return pricing.quote(req)

When to graduate to code

Low-code buys speed at the cost of control, and the crossover is predictable. Move it into a repository when any of these is true:

• The workflow has more than a handful of branches, or a loop with a condition.
• A business rule inside it needs review, tests, or an audit trail.
• Per-task billing has become a real line item.
• Two people have broken it in the canvas.
• It needs to run inside your network against private data.

The reverse is also worth saying: do not start in code. A workflow that might be deleted in three weeks does not deserve a repository, a CI pipeline and a deploy. Prototype in the low-code tool, and port the ones that survive.

Related

• n8n and low-code automation - n8n in depth, queue mode and the AI nodes.
• Webhooks
  • the trigger side of most of these workflows.
• Idempotency
  • why a platform retry is not safe on its own.
• Temporal vs Celery vs Other Orchestrators
  • the code-first end of the same spectrum.
• Process mapping and choosing what to automate
  • deciding what to automate before choosing a tool.
• Designing an external API integration
  • owning the contract on your side.