Why is my Make.com webhook not working?
A Make webhook usually fails for one of six reasons: the scenario is off or scheduled, the webhook was deactivated, the queue is full, the sender hit the rate limit, the data does not match the stored structure, or the payload is over 5 MB.
The fastest way to find which one is to look at the HTTP status code the sending app got back. Make returns a different code for almost every failure, and each code points to one fix. This page lists them, with the limits from Make's own documentation, checked October 30, 2026. If the problem is a whole scenario that keeps failing or switching off, our Make scenario build and repair service page covers error handlers and incomplete executions in depth; this page stays on the webhook itself.
What does each Make webhook status code mean?
200 "Accepted" means Make queued the request. 400 means the queue is full or the data failed validation. 410 means the webhook was deactivated. 429 means too many requests. 500 means the scenario failed while a Webhook response module was waiting to reply.
Read the code the sender got back
| Code the sender gets | Body | What it means | Fix |
|---|---|---|---|
| 200 | Accepted | Make put the request in the webhook's queue. It does not mean the scenario ran. | If nothing ran, check the scenario is on and set to run immediately (next section) |
| 400 | Queue is full | The webhook's queue has hit its limit, so Make rejects new data | Clear the backlog: turn the scenario on, fix the error that stopped it, or raise your credits (the queue size depends on them) |
| 400 | (validation error) | The request did not match the data structure set on the webhook | Change the data structure, or remove it and let Make detect fields again |
| 410 | Gone | The webhook was not linked to any scenario for more than 5 days (120 hours) and Make deactivated it | Create a new webhook in the scenario and give the sender the new URL |
| 429 | Too many requests | More than 300 requests arrived in 10 seconds | Have the sender spread or batch its requests |
| 500 | Scenario failed to complete. | A Webhook response module was in the scenario and a module before it failed | Open the scenario history, fix the failing module, add an error handler |
| 200 after 3 minutes | Accepted | Your scenario took longer than 180 seconds to reach the Webhook response module | Reply earlier in the scenario, or return a job ID and send the result later |
The codes and limits come from Make's webhooks guide and its Webhooks app reference. If the sender shows no code at all, the request may never have left it: check the sending app's own log first.
Why does my Make webhook receive data but the scenario does not run?
The webhook only stores the request in a queue. The scenario must be switched on and scheduled to run immediately to pick it up. If the scenario is off, set to a schedule, or was deactivated after an error, data waits in the queue.
Make's webhooks guide says each webhook has its own queue, and that a scheduled webhook scenario processes the whole queue each time its schedule comes round. So a scenario set to run every 15 minutes, which is Make's default schedule according to its scheduling guide, will look broken for up to 15 minutes after each request. Check three things in this order:
- The scenario's on/off switch. A scenario that starts with a webhook is an instant scenario. Make's scenario settings guide says an instant scenario is deactivated immediately after its first error, whatever you set as the number of consecutive errors allowed. One bad request can switch it off.
- The schedule. Open the clock icon on the trigger and set it to run immediately, unless you batch on purpose.
- Process data in order. With this setting on, Make waits for each run to finish before starting the next. Make's settings guide says runs stay paused until stored incomplete executions are resolved, so one stuck run can hold up the queue behind it.
Turned it back on and old data ran? That is the queue doing its job. Requests that arrived while the scenario was off are processed when it comes back, as long as the queue did not fill. If you do not want them processed, check the webhook's queue before you switch the scenario on.
How big is a Make webhook queue, and when does it fill?
Make allows 667 queued items per webhook for every 10,000 credits in your plan each month, up to 10,000 items. A plan with 10,000 credits therefore holds 667 waiting requests; past that, Make rejects new data with 400 "Queue is full".
Webhook queue limit by plan size
We worked out the queue size for a few plan sizes from the rule on Make's pricing page and webhooks guide (667 items per 10,000 credits a month, 10,000 maximum). The fill time assumes the scenario is off and requests keep arriving at a steady rate, which is the usual way a queue fills.
| Credits in plan per month | Queue limit per webhook | Fills in (at 1 request a minute) | Fills in (at 10 requests a minute) |
|---|---|---|---|
| 10,000 | 667 | about 11 hours (667 minutes) | about 67 minutes |
| 40,000 | 2,668 | about 44 hours | about 4.4 hours |
| 100,000 | 6,670 | about 4.6 days | about 11 hours |
| 150,000 and above | 10,000 (the maximum) | about 6.9 days | about 17 hours |
Arithmetic: queue limit = credits / 10,000 x 667, capped at 10,000 (150,000 / 10,000 x 667 = 10,005, so the cap applies). Fill time = queue limit / requests per minute. The point of the table: on a small plan, a webhook scenario that switches itself off on a Friday evening can start rejecting data before Saturday morning. That is why we put an alert on deactivation for every webhook scenario we build.
Why are fields missing or empty after my Make webhook?
Make maps fields from the sample request it saw when the webhook was set up. If the sender later adds or renames fields, later modules cannot see them until you open the webhook and click "Detect new values", then send a fresh sample request.
Make's Webhooks app reference gives this as the fix for missing values. Three related settings cause the same symptom:
- A data structure that no longer fits. If you attached a data structure to the webhook, requests that fail validation against it are rejected with HTTP 400. Update the structure when the sender changes its payload.
- JSON pass-through switched on. The whole JSON body then arrives as one text string instead of separate fields. Turn it off, or add a Parse JSON module.
- Headers you need but cannot see. Request headers are only available to map when "Get request headers" is on. The
x-make-apikeyheader is removed before your scenario sees it.
When the sender is GoHighLevel, the payload changes with the workflow trigger, so a webhook built on one trigger often misses fields from another. Our guide to sending GoHighLevel data out by webhook or API shows which route fits which job.
Why does the sender get "Accepted" instead of my webhook response?
Make waits 180 seconds for a Webhook response module. If the scenario has not reached it by then, Make answers with HTTP 200 and the body "Accepted". Without any Webhook response module, "Accepted" is always the default reply.
What Make sends back, and when
This trips up forms and apps that wait for an answer, such as a booking widget that expects a confirmation ID back. Make's Webhooks app reference states the 180-second limit. Two fixes work:
- Move the Webhook response module up. Reply as soon as you have what the sender needs, then do the slow work after it. Make's webhooks guide notes a side effect: errors in modules after a mid-scenario response do not deactivate the scenario, so add your own error alert.
- Reply with a job ID. Return a reference straight away and send the full result later by email, text or a call back to the sender's API, which is the kind of two-way link our API integration work covers.
A single slow module can eat the whole window. Make's errors and warnings guide says most modules wait up to 40 or 60 seconds for an app to respond before they time out, so three slow API calls in a row can pass 180 seconds.
Why did my Make webhook stop working after it worked for weeks?
The usual causes are a scenario that deactivated itself after one error, a webhook left unlinked for more than 5 days that now returns 410, a queue that filled while the scenario was off, or a sender that changed its payload or its rate.
| Symptom | Cause | Fix |
|---|---|---|
| Scenario switch is off; history shows one red run | Instant scenarios deactivate at the first error | Add error handlers to modules that can fail, turn on incomplete executions, then switch it on |
| Sender logs 410 Gone | You rebuilt or cloned the scenario and the old webhook sat unlinked for 5 days | Use the current webhook URL in the sender |
| Sender logs 400 Queue is full | Scenario was off long enough for the queue to fill (see the table above) | Fix the error, switch on, and alert on deactivation next time |
| Some requests get 429 | A bulk import or sync now sends more than 300 requests in 10 seconds | Slow the sender down, or send records in batches |
| Sender logs a size error | The payload is over 5 MB; Make's limit applies on every plan | Send a file link instead of the file, or split the payload |
| Requests from one system are ignored | An IP allowlist on the webhook does not include the sender's new address | Update the allowlist (CIDR ranges are accepted) or clear it |
| Nothing in the sender's log at all | The sending app's own trigger or workflow stopped | Fix the sender; for HighLevel, see our inbound webhook FAQ below |
Make keeps webhook logs for 3 days (30 on Enterprise), according to its webhooks guide, so look as soon as you notice a gap. Requests older than that leave no trace in Make.
More questions about Make webhooks
Is there a size limit on Make webhooks?
Yes. Make's Webhooks app reference limits a webhook payload to 5 MB (5,242,880 bytes) on every plan. An email sent to a Make mailhook can be up to 25 MB with attachments. For files larger than that, send a link to the file and download it inside the scenario. Zapier's limits differ; our Zapier webhook payload limit page has those.
How many requests a second can a Make webhook take?
Make's webhooks guide says it processes up to 300 incoming webhook requests per 10-second interval, which averages 30 a second. Requests over that get HTTP 429 "Too many requests". By default instant webhook scenarios run in parallel, so Make does not wait for one run to finish before starting the next unless you turn on Process data in order.
Why does my Make webhook return 410 Gone?
Make automatically deactivates a webhook that has not been connected to any scenario for more than 5 days, and a deactivated webhook returns 410 Gone. This usually happens after someone rebuilds a scenario with a new webhook and forgets to update the sender. Copy the webhook URL from the live scenario and paste it into the sending app.
Does a Make webhook use credits?
Each run of the trigger module counts like any other module run. Make's credits guide says that for non-AI apps one operation equals one credit, so every request that starts the scenario uses at least one credit, plus one for each later module that runs. Because a webhook only runs when data arrives, it avoids the credits a polling trigger spends on empty checks.
Can I test a Make webhook without the real app?
Yes. Copy the webhook URL and send a request to it from any HTTP tool, using a sample body shaped like the real one. Then click Detect new values if fields are missing. Test with a realistic payload, including long text fields and lists, so you see size and mapping problems before the real sender does.
Is a Make webhook like an n8n test and production URL?
No. A Make custom webhook has one URL, and whether data is processed depends on the scenario being on. n8n gives each webhook node separate test and production URLs, which is a common reason n8n webhooks seem to fail. Our n8n test vs production webhook URL FAQ explains that one.
My GoHighLevel workflow sends to Make but nothing arrives. Where do I look?
Start in HighLevel: open the workflow's execution log and check the webhook action ran and what response it got. A 200 means Make queued it, so the problem is on the Make side. No entry means the HighLevel trigger did not fire; our GoHighLevel webhook not firing FAQ covers the receiving direction.
Can you fix our Make webhooks for us?
Yes. We start with a free audit of your scenarios: each webhook, its sender, its queue and its recent errors. Then we fix the ones that fail, add error handlers and a deactivation alert, and write a short note on each. A small build of two or three automations is about $1,000 at the time of writing, and fixes to what we build are free for 6 months.
Sources and further reading
- Make Help Center, Webhooks (queues, 667 items per 10,000 credits, 10,000 maximum, status codes 200, 400, 429, 410, 300 requests per 10 seconds, 5-day deactivation, 3-day logs), read October 30, 2026.
- Make Apps, Webhooks app reference (5 MB payload limit, 25 MB mailhook, 180-second response wait, 500 "Scenario failed to complete.", Detect new values, JSON pass-through, headers, IP allowlist), read October 30, 2026.
- Make Help Center, Scenario settings (instant scenarios deactivated at the first error, Process data in order, incomplete executions), read October 30, 2026.
- Make Help Center, Schedule a scenario (default 15-minute schedule, Immediately option), read October 30, 2026.
- Make Help Center, Fix errors and warnings (module timeouts of 40 or 60 seconds, RateLimitError), read October 30, 2026.
- Make Help Center, Credits (one operation equals one credit for non-AI apps), read October 30, 2026.
- Make pricing page (usage allowance per 10,000 credits, including webhook queue), read October 30, 2026.
Make changes limits from time to time. If a number here differs from what your account shows, Make's current documentation wins.
