Make.com Webhooks: Custom Webhooks, Mailhooks and Fixes

Make.com webhooks let other apps start a scenario instantly by sending data to a unique URL. You create a Custom webhook module as the scenario trigger, copy the URL into the sending app, send one sample request so Make learns the data structure, and switch the scenario on. A mailhook does the same thing with an email address instead of a URL. If you see "There is no scenario listening for this webhook", the webhook exists but no active scenario is using it, which usually means the scenario is switched off or the webhook was detached.

Webhooks are how I trigger almost every scenario that needs to react quickly, including the production alerts on my work page. This guide covers setup, the queue, responses, limits and the fixes for common errors.

Custom webhook vs app webhooks vs mailhooks

Make has a few kinds of instant triggers:

• Custom webhook: a generic URL any app can call. You define the data structure from a sample. This is what you use for GoHighLevel, form tools, cold email tools and your own code.
• App-specific instant triggers: many app modules use webhooks behind the scenes, like a "Watch" trigger marked as instant. Make registers the webhook with the app for you.
• Mailhook: an email address generated by Make. Every email sent or forwarded to it starts the scenario, with the sender, subject, body and attachments as data.

How to set up a Make.com custom webhook

1. Create the trigger. In a new scenario, add Webhooks and choose "Custom webhook". Click Add, name the webhook clearly, for example "GHL won deal to onboarding".
2. Copy the URL. Make shows the address. Copy it.
3. Make it listen. Make waits for a sample request to determine the data structure.
4. Send a sample. From the sending app, trigger a test with every field populated. Empty fields in the sample mean missing fields in the mapping panel later.
5. Confirm the structure. Make shows "Successfully determined". If you need to add fields later, use "Redetermine data structure" and send a new sample.
6. Build the rest of the scenario. Map the webhook fields into your next modules.
7. Switch the scenario on. Instant triggers run immediately when data arrives, as long as the scenario is active.

A naming tip: include the source and purpose in the webhook name. When you have forty webhooks, "Webhook 12" is useless.

Make.com mailhook setup

Mailhooks are underrated. Any system that sends email notifications becomes a trigger:

1. Add Webhooks and choose "Custom mailhook". Make generates an email address.
2. Forward a sample email to it, or set up a forwarding rule in Gmail or Outlook so specific emails go there automatically.
3. Use a Text parser module with "Match pattern" to extract the values you need from the email body.
4. Filter so only the emails you care about continue.

I built the failed-payment alerts scenario this way: billing emails are forwarded to a mailhook, parsed into invoice, contact and amount, then billing is pinged in Slack and a ClickUp task is logged. When a tool has no API or webhooks, this approach still works. My Gmail parsing automation guide goes deeper on parsing.

Fixing "There is no scenario listening for this webhook"

This message comes back when a request reaches a webhook that is not attached to an active scenario. Check, in this order:

1. Is the scenario switched on? Testing with Run once does not keep it listening afterwards. Toggle the scenario on.
2. Is the scenario using this webhook? Open the trigger module and confirm the selected webhook is the one whose URL you copied. It is easy to create a second webhook by accident.
3. Was the scenario deactivated after an error? Instant-trigger scenarios can be deactivated after an error. Check the scenario history, fix the error and switch it back on. See Make.com error handling.
4. Was the webhook detached for too long? According to Make's webhook documentation, webhooks not connected to a scenario for more than 5 days return 410 Gone. You may need a new webhook and to update the URL in the sending app.
5. Is the URL correct in the sender? Check for copy errors or an old URL from a deleted scenario.

The webhook queue

Each webhook has its own queue, visible in the Webhooks section. When data arrives:

• If the scenario is set to run immediately, Make processes each request as it arrives, in parallel by default.
• If you enable sequential processing in scenario settings, runs happen one at a time in arrival order.
• If the scenario is scheduled instead of immediate, requests wait in the queue until the scheduled run.

Make's documentation says queue size scales with your plan's credits, up to a maximum, and that requests beyond the limit are rejected. Queued items are removed once processed. If a scenario is off, requests can pile up in the queue and be processed when you switch it back on, which may or may not be what you want.

Limits to know

From Make's webhook documentation, checked for this article:

• Make can process up to 300 incoming webhook requests per 10-second interval. Requests over that get a 429 response.
• Queue size is tied to licensed credits, with a cap on items per webhook.
• Webhook logs are kept for a few days on most plans, longer on Enterprise.

If you send bursts of data, like a bulk import, spread it out or batch it into fewer requests with arrays.

Make webhook response

By default, Make replies to the sender with a simple status: 200 Accepted when queued, 400 when the queue is full, 429 when rate limited. If the sender needs a custom reply, for example a JSON body or a redirect, add a "Webhook response" module.

Placement matters. If you put the Webhook response early in the scenario, the sender gets a reply fast, but later errors may not be reported back. If you put it last, the reply reflects the full run, but the sender waits longer. For most alerts, I do not need a custom response. For form handlers that show a result to a user, I place it after the key steps succeed.

Securing your webhooks

A webhook URL is effectively a password. Anyone with it can trigger your scenario. Basic precautions:

• Do not post webhook URLs in shared docs or public code.
• Add a shared secret field to the payload or a header and filter on it as the first step.
• Validate required fields early and stop if they are missing.
• Rotate the webhook if a URL leaks.

Debugging webhook problems

1. Check the webhook's queue and logs to see if the request arrived at all.
2. Check the scenario history to see if a run started and where it stopped.
3. If nothing arrived, test from the sender with a request bin to confirm what it sends.
4. If data arrived but fields are missing, redetermine the data structure with a complete sample.

How I build this

I connect GoHighLevel, form tools, cold email platforms and billing systems to Make through webhooks and mailhooks, with secrets, validation and error alerts. See my API integrations service, or if a webhook scenario keeps going quiet, the Automation Rescue fixes it in 48 hours. You can also request a free 15-minute Loom teardown.

FAQ

What does "There is no scenario listening for this webhook" mean?

The webhook exists but no active scenario is using it. Switch the scenario on, confirm the trigger uses that exact webhook, and check whether the scenario was deactivated after an error.

What is a mailhook in Make.com?

A mailhook is an email address that triggers a scenario. Every email sent or forwarded to it starts a run, with the email's sender, subject, body and attachments available as data.

How do I add new fields to a Make.com webhook?

Open the Custom webhook module, choose to redetermine the data structure, and send a new sample request that includes the new fields.

Are Make.com webhooks instant?

Yes, when the scenario is active and set to run immediately. If the scenario is scheduled, requests wait in the webhook queue until the next scheduled run.