# Make Alternatives for Webhooks: Hookdeck Event Gateway, n8n, Zapier, and Pipedream Compared Make (formerly Integromat) is the visual automation tool people move to when Zapier's linear Zaps get limiting. Scenarios are built on a canvas with routers, iterators, and error handlers, and pricing is per credit rather than per task. Many scenarios start with a custom webhook: Stripe, Shopify, or a form tool posts an event, and Make runs the scenario. People look for Make alternatives for three different reasons: 1. Your webhooks need a sturdier gateway. The webhook queue fills up and starts rejecting events, a scenario was disabled after one error and events piled up behind it, provider retries create duplicate runs, and you're computing HMACs in filters. You don't want to leave Make; you want something in front of it that owns the ingress edge. 2. Your scenario is really just receive, transform, forward. It's a custom webhook, a few mapped fields, and an HTTP module that posts to another API. You're spending credits on every event for a job a webhook gateway does on its own. 3. You want a different automation tool. You want self-hosting, code-first steps, or a bigger app catalog. This guide covers all three. ## How to evaluate a Make alternative Make bundles two jobs that are worth judging separately: receiving a webhook and running the scenario that acts on it. A useful comparison names which job each tool does: Ingress vs orchestration: Is the tool receiving and holding webhooks from third parties (a gateway), or running multi-step logic across apps (a workflow tool)? Queue depth: How many events can wait while the workflow is busy, off, or broken, and what happens when that limit is reached? Signature verification: Does the tool verify Stripe, Shopify, and GitHub signatures, or do you build the check yourself? Retries and replay: Is the original event redelivered automatically if a run fails? Can you replay past events in bulk? Burst handling: What happens when a provider sends thousands of events in a few seconds? Deduplication: Do provider retries become duplicate runs? Pricing model: Per credit (Make), per task (Zapier), per execution (n8n), or per event (gateways)? ## What Make does well Make is good at what it's built for: * A capable visual canvas: Routers, iterators, aggregators, and filters make branching and looping workflows easier to build and read than in a linear tool. * Per-credit pricing: Most module runs cost one credit, and Make's Core plan starts at $12/month for 10,000 credits. Routers and error handlers don't use credits. * A webhook queue: Make's custom webhook stores incoming events in a queue when a scenario can't process them right away, which Zapier and n8n don't do. * Custom responses: The Webhook response module sets the status code, body, and headers returned to the sender. * Error handlers and replay: Retry, Skip, Resume, Commit, and Rollback handlers, stored incomplete executions, and a "Replay run" option that re-runs a past run with its original trigger data. * AI and agents: Make AI Agents, an MCP server that exposes scenarios as tools, and a built-in Claude connector. If your automations branch across several apps and your team wants a canvas, Make is a strong choice. ## Where Make falls short for webhooks (and why people look for alternatives) The queue is small, and a full queue rejects events. Make's webhook queue holds 667 items per 10,000 credits on your plan, per webhook, up to a maximum of 10,000. On a 10,000-credit plan, that's 667 events. Once it's full, Make rejects everything over the limit with a `400 Queue is full`, and doesn't retry. Whether those events survive depends on whether the sender retries. One error can stop a scenario. A scenario with an instant trigger, like a webhook, is [disabled after its first error](https://help.make.com/Overview-of-error-handling.md); the consecutive-errors setting doesn't apply to it. Events then pile up in the queue until it fills, and after that they're rejected. Errors on the first module don't create an incomplete execution unless a Retry handler is attached, and storing incomplete executions is off by default. No signature verification. Custom webhooks support an API key header and an IP allowlist, but don't verify HMAC signatures. The workaround is to turn on JSON pass-through and request headers, compute the HMAC with Make's functions, and compare it in a filter. Make doesn't document that pass-through gives you the exact bytes the sender signed, and any re-serialisation breaks the check. Make's new outbound event subscriptions do sign what Make sends; there's no equivalent for what it receives. Rate limits and size limits. Make processes up to 300 webhook requests per 10-second window and returns a 429 above that. Payloads are capped at 5 MB on every plan. A webhook that isn't connected to a scenario for more than 5 days is deactivated and returns a 410. Parallel by default, so ordering isn't guaranteed. Instant scenarios process webhooks in parallel. "Process data in order" makes runs sequential, but then new runs wait until incomplete executions are resolved. No deduplication. Provider retries become separate runs. The workaround is a data store lookup on each event ID before doing any work, which costs credits on every event. Credits on every event, including the ones you ignore. Every module that runs on an event uses credits, so a stream where most events are irrelevant still pays to receive and filter each one. Our guide on [reducing Make credit usage](/webhooks/platforms/how-to-reduce-make-com-credit-usage) covers this. These gaps are all in the ingress layer, where Make's queue is fine at low volume and tight at high volume. The [Make rate limit guide](/webhooks/platforms/how-to-solve-make-com-webhook-rate-limit-errors) goes deeper on bursts. ## Make alternatives Which alternative fits depends on which problem you have: * [Hookdeck Event Gateway](/event-gateway): For the ingress problem, and for scenarios that only receive, transform, and forward. A managed webhook gateway with 160+ pre-configured sources, signature verification, a durable queue, filters, JavaScript transformations, deduplication, retries, and replay. * n8n: A visual workflow tool with code nodes, per-execution pricing, and a free self-hosted edition. * Zapier: The largest app catalog and the easiest setup, priced per task. * Pipedream: Code-first workflows in Node.js or Python, now part of Workday and its Workflows product is being deprecated. * DIY (serverless function + queue): A Cloudflare Worker or Lambda with a queue, when you want code and nothing else. ### Hookdeck Event Gateway (for the ingress problem) [Hookdeck Event Gateway](/event-gateway) sits between the provider and Make. Webhooks arrive at a Hookdeck source URL, get verified against the provider's signing secret, get deduplicated and held in a durable queue, and get delivered to your Make webhook at a rate below Make's limits. Make's queue never has to absorb a burst, because Event Gateway does. #### Hookdeck Event Gateway key features * 160+ pre-configured sources: Stripe, Shopify, GitHub, Twilio, and the rest ship with [signature verification](/docs/sources), so you can drop the HMAC filter from the scenario. * A queue that accepts everything: Inbound requests are always accepted. Events above your delivery rate wait in Hookdeck's queue instead of filling Make's. * Rate limits per destination: Cap deliveries per second, minute, or hour, or set concurrency to 1 for strictly serial delivery. See [max delivery rate](/docs/destinations#set-a-max-delivery-rate). * Retries: Up to 50 automatic retries with linear or exponential backoff, plus manual and [bulk retry](/docs/retries). If Make answers a delivery with a 400 or 5xx, Event Gateway retries it. * Pause and resume: If a scenario is disabled, [pause the connection](/docs/guides/how-to-pause-connections). Event Gateway keeps accepting and storing events and delivers them once the scenario is back. * Deduplication: Drop repeat events within a window from 1 second to 1 hour, before they cost a credit. See [deduplication](/docs/deduplication). * Filters: Drop events the scenario ignores before they reach Make, so they never use credits. * Observability: Full-text search across payloads and headers, a trace per request, and [Issues](/docs/issues) with alerts by email, Slack, or webhook. #### When Hookdeck replaces Make outright A common scenario is a custom webhook, a few mapped fields, and an HTTP module. A Hookdeck connection does the same job: the source receives and verifies the webhook, a [transformation](/docs/transformations) reshapes the payload and headers in JavaScript, and the destination posts it to the target API with an API key, bearer token, basic auth, or a custom signature. You get queueing, retries, and replay on that hop, priced per event: 10,000 a month free on the Developer plan, then $3.00 per 100,000 on paid plans, falling with volume. The limit is that transformations can't make network calls and Event Gateway has no app modules. Once a scenario calls a second API, routes between apps, or iterates over results, keep Make and put Event Gateway in front. #### How does Hookdeck Event Gateway compare to Make?
Capability Hookdeck Event Gateway Make
Primary role Webhook gateway / ingress edge Visual automation / orchestration
Queue when the workflow is busy or off ✅ Always accepts, queued per connection ℹ️ 667 items per 10k credits, max 10,000; then 400
Provider signature verification ✅ 160+ pre-configured sources ❌ DIY with filters and hash functions
Burst handling ✅ Queue, then deliver at your rate ℹ️ 429 above 300 requests per 10 s
Max payload 10 MiB by default 5 MB
Automatic redelivery of the original event ✅ Up to 50 retries ℹ️ Incomplete executions, for some error types
Deduplication ✅ 1 s to 1 h window ❌ DIY with data stores
Replay ✅ Single and bulk ℹ️ Replay run, one at a time
App modules and branching ❌ One hop: filter, transform, deliver ✅
Pricing model Per event; free for 10,000/month, Team from $39/month Per credit; Core from $12/month for 10,000 credits

### n8n (self-hosted, per-execution pricing) n8n is the closest alternative to Make's canvas for technical teams. Workflows mix visual nodes with JavaScript or Python, and pricing is per execution, so a long workflow costs the same as a short one. The Community Edition is free to self-host, which Make doesn't offer. The trade-off is that n8n has no inbound webhook queue at all: if the instance is down or the workflow is unpublished, the sender gets an error. Hookdeck's [verified n8n node](/blog/hookdeck-n8n-node) covers that gap. See [n8n alternatives](/webhooks/platforms/n8n-alternatives). ### Zapier (the biggest app catalog) Zapier has over 8,000 apps and the easiest setup, which is why many teams start there before moving to Make. Pricing is per task, where each action step costs one, so the same multi-step workflow usually costs more than on Make. Webhooks by Zapier needs a paid plan, doesn't verify signatures, and doesn't capture events sent while a Zap is off. See [Zapier alternatives](/webhooks/platforms/zapier-alternatives). ### Pipedream (code-first workflows, being deprecated) Pipedream suits developers who'd rather write each step as Node.js or Python than map fields between modules, while keeping a large catalog of pre-built actions and managed auth. Pipedream was acquired by Workday, and its Workflows product is being deprecated: it's in maintenance mode and [shuts down on March 31, 2027](/webhooks/platforms/pipedream-alternatives), so it isn't an option for new work. It's a workflow tool with an HTTP trigger, so the ingress gaps above apply to it as well. ### DIY (serverless function + queue) If the scenario is one transform and one API call, a [Cloudflare Worker](/webhooks/platforms/cloudflare-workers-alternatives) with Cloudflare Queues, or Lambda with [SQS](/webhooks/platforms/aws-sqs-alternatives-for-webhooks), does it cheaply. You'll write signature verification, deduplication, and replay yourself. ## When to keep Make Make is the right tool, and worth keeping, when: * Your scenarios branch across several apps. Routers, iterators, and aggregators across CRM, email, and spreadsheet modules are what Make is for. * Your team wants a canvas. People who don't write code can build and change scenarios. * Volume fits the queue. At low and steady volume, Make's queue and rate limit are rarely reached. * You're using Make AI Agents or the MCP server. Exposing scenarios to agents is something a gateway doesn't replace. The reason to add or switch tools is usually that webhooks need guarantees Make's queue can't give at your volume, or that the scenario was simpler than a workflow tool assumes. ## Using Hookdeck Event Gateway and Make together For teams that want Make's canvas and reliable webhooks, the answer is both. Event Gateway owns delivery into Make, and Make owns the scenario: 1. Providers send signed webhooks to a Hookdeck source URL. 2. Event Gateway verifies the signature, deduplicates, and filters out events the scenario doesn't need. 3. Event Gateway delivers each event to the Make webhook URL at a rate below Make's limits, and retries if Make answers with an error. 4. The scenario runs. Make's queue stops being the safety net, because nothing reaches it faster than it can drain. A disabled scenario doesn't lose events, because you pause the connection until it's fixed. Duplicates and irrelevant events are dropped before they use credits. Hookdeck's [Make rate limit guide](/webhooks/platforms/how-to-solve-make-com-webhook-rate-limit-errors) walks through the setup. ## Choosing the right Make alternative If you searched for a Make alternative because the webhook queue fills up, scenarios get disabled and events back up, or you're checking signatures in filters, you don't need a different automation tool. You need a webhook gateway in front of Make. [Hookdeck Event Gateway](/event-gateway) owns that layer. If your scenario only receives, reshapes, and forwards to one API, Hookdeck Event Gateway can replace it. And if you want a different automation tool, n8n suits technical teams and self-hosting, Zapier has the biggest catalog and easiest setup, and developers who'd rather write each step as code can use a runtime like Trigger.dev or Inngest, since Pipedream's Workflows product is being deprecated.