You created a Webhooks → Custom webhook module in Make, pointed your
app at the hook.*.make.com/… URL, and the scenario never runs. Make's failure
modes are unusually diagnosable, because the HTTP response your sender gets back
tells you which one you have. Start there.
| Sender receives | What it means |
|---|---|
200 — body Accepted | The request reached Make and was accepted. If the scenario still didn't run, your problem is the queue or scheduling (causes 1–2 below) — not delivery. |
400 — Webhook temporarily disabled | The webhook itself is toggled OFF (independent of the scenario). The data is not stored anywhere — it's lost. Cause 3. |
400 — Queue is full | The webhook queue hit your plan's item limit; new requests are rejected. Cause 4. |
400 — validation error | You attached a data structure and the request doesn't match it. Cause 5. |
500 — Failed to complete | Your scenario uses a Webhook response module and errored before responding. |
Can't see what your sender receives? Point it at a
capture bin first — you'll see the exact request it makes (method,
content-type, raw body), then replay that request to your real
hook.*.make.com URL and read Make's response yourself with curl.
This is Make's biggest trap, and it's the opposite of what most senders assume: an inactive scenario still returns 200. When the scenario is OFF, Make accepts the request and parks it in the webhook queue — your sender sees success, nothing executes, and (unlike the disabled-webhook case) nothing errors anywhere. Requests also go to the queue when:
Check it: right-click the Custom webhook module → Show queue, or open Webhooks in the left sidebar — each webhook shows a queue counter. When you turn the scenario back ON, Make asks whether to process or delete the queued items; queued items are only consumed when the scenario actually executes.
A custom webhook is an instant trigger, but the scenario decides when queued data gets processed. If Schedule settings say anything other than Immediately (every 15 minutes, daily, On demand…), incoming requests are acknowledged and queued until the next scheduled run. That looks exactly like "webhook not triggering" if you expected real-time. The tell: the first module shows a clock icon (scheduled) instead of a lightning bolt (immediate). Fix: Schedule settings → Immediately. You can also cap runs-per-minute (1–10,000) there — a low cap plus a burst behaves like a delay too.
Every Make webhook has an ON/OFF toggle separate from the scenario's. If the
webhook is OFF, Make answers 400 with "Webhook temporarily disabled" and —
unlike the scenario-off case — does not queue the data. Whatever was sent
during that window is gone; you'll need the sender to re-send (or replay the captures you
made while diagnosing). Toggle it in the Webhooks sidebar page.
The queue's item limit depends on your subscription plan. Once it's full, further
requests get 400 Queue is full — so a scenario that's been OFF for a while
can silently transition from "accepting into queue" to "rejecting everything". Clear or
process the queue, and if this recurs, raise throughput (Immediately + higher
runs-per-minute) or plan tier.
If you attached a data structure to the webhook, Make validates every
incoming request against it and rejects mismatches with 400. Remember what
the parser accepts in the first place: query string, form data, and JSON
— that's the list. A sender posting XML or a bare text body won't produce mappable fields.
Also note the merge rule: if the same key arrives in both the query string and the body,
the query-string value wins. And the payload cap is
5 MB (Content-Length), on every plan.
Not sure which format your app actually sends? That's precisely what a
capture bin shows you — the real Content-Type and the raw
bytes, before Make's parser gets an opinion. (Receiving files via
multipart/form-data additionally requires a data structure with a collection field
containing name / mime / data-buffer subfields.)
The "webhook fires but later modules see no data" variant. Make learned the data shape from the first sample request it saw; fields that weren't in that sample don't exist for mapping. Open the Custom webhook module → Detect new values (redetermine data structure) → send a fresh, complete sample request. New fields become mappable.
Headers are not captured by default. Enable Get request headers
(and Get request HTTP method if you need it) under the webhook's advanced
settings. Two adjacent gotchas: the x-make-apikey header is reserved for
Make's own API-key auth and is sanitized out — you'll never see its value in the bundle —
and if you configured IP restrictions on the webhook, requests from
unlisted IPs are dropped, which is worth ruling out when "nothing arrives" from one
particular sender.
By default Make answers 200 Accepted immediately. If your sender requires
an echoed token, JSON, or specific headers, add a Webhook response module
(status + body + Content-Type header). Deadline: Make waits 180 seconds
for your scenario to produce the response, then gives up and returns
200 Accepted anyway — slow scenarios silently fall back to the default. Test
what your sender actually requires against a bin first: bins let you configure the
response status, headers, body, and even
computed handshake responses
without burning scenario operations.
hook.*.make.com URL with curl → read the
response body against the table above.200 Accepted but no run? → check the queue and the
schedule icon (clock vs lightning bolt).Same debugging job on the other big automation platform: Zapier webhook not triggering — where the trap is a paid-plan-only trigger and a stale 200 after a Zap turns off, rather than a queue.
No signup needed. Or from your terminal: curl https://hookden.pages.dev/new
← All guides · Signature debugger · Payload examples · Docs · Hookden vs webhook.site