Make.com Webhook Response Guide

Most webhook triggers in Make.com never need a custom response. The caller fires the request, Make accepts it, and processing happens asynchronously afterward with nobody waiting on the reply. But the moment the calling system actually needs something back, a confirmation, a lookup result, a redirect, a specific status code it checks before proceeding, the default response is not enough, and that is exactly what the Webhook Response module exists to control.

I reach for this module specifically when a scenario is acting as a real API endpoint rather than a fire-and-forget trigger, something a website form, a custom integration, or another system is actually waiting on a meaningful reply from. This post covers what the default response looks like, how to customize it, and where response timing actually matters.

What a Webhook Response Does

By default, a Custom Webhook in Make responds to the caller immediately upon receiving the request, before the rest of the scenario has necessarily finished running. Adding a Webhook Response module to your scenario lets you override that default, controlling the exact HTTP status code, headers, and body sent back to whoever called the webhook, rather than accepting Make's built-in reply.

Default Make Webhook Responses

If your scenario does not include a Webhook Response module, Make replies with a simple default. For a successful trigger, that is HTTP 200 with a body reading "Accepted." If the webhook's queue happens to be full at the moment the request arrives, the default response is HTTP 400 with a body reading "Queue is full," which is worth recognizing as a distinct signal from a genuine processing failure if you ever see it in a caller's logs, since it points specifically at the queue backlog issue covered in Make.com Webhook Queue Explained rather than anything wrong with the request itself.

Custom HTTP Status Codes

The Webhook Response module lets you set any valid HTTP status code in its Status field, useful whenever the calling system checks the response code to decide its own next step. Returning 200 for a straightforward success, 201 when the request resulted in something being created, or an appropriate 4xx or 5xx code when the scenario's own logic determines the request could not actually be processed, gives the caller accurate information to act on rather than a blanket success regardless of what actually happened.

Returning JSON

For the Body field, you can return JSON, plain text, HTML, or essentially anything the calling system can parse. A common pattern: build the response data with a JSON module earlier in the scenario, then map that generated JSON string into the Webhook Response module's Body field, along with a Content-Type: application/json header so the receiving system correctly interprets what it is getting back rather than treating it as plain text.

Response Timing

Where the Webhook Response module sits in your scenario determines when the caller actually receives the reply, since it responds at the moment execution reaches that specific module, not automatically at the very end of the scenario. If you place it after several time-consuming steps, the caller waits for all of that processing to complete before getting anything back. If the caller does not actually need to wait on the full processing to finish, placing the response module earlier and letting the rest of the scenario continue independently afterward keeps the caller from sitting through delay it does not need.

Where to Put Webhook Response

For a scenario branching into multiple routes depending on the incoming data, place a Webhook Response module on each relevant route rather than trying to centralize a single response point after branching has already happened, since each branch may need to return meaningfully different information depending on what it actually did. A found-versus-not-found lookup scenario is a common example: one route returns the found record as JSON, a fallback route returns a 404 with an appropriate message, each needing its own distinct response.

Handling Errors

If your scenario's own logic determines a request cannot be fulfilled, invalid input, a lookup that found nothing, a downstream API failure, route that specifically to its own Webhook Response module returning an appropriate error status and a body explaining what went wrong, rather than letting the default 200 "Accepted" response mislead the caller into believing everything succeeded when it did not. A caller checking only the HTTP status code has no way to know the actual outcome unless your response accurately reflects it.

Testing With Postman

Test a custom webhook response directly with a tool like Postman rather than only through whatever system will eventually call it in production. Send a realistic request, check the status code, headers, and body all come back exactly as configured, and specifically test any error paths deliberately, sending input designed to trigger the failure branch, since those are the paths most likely to be skipped during casual testing focused mainly on the success case.

If you are building a Make.com scenario that needs to act as a real API endpoint, returning specific status codes or structured JSON rather than the default accepted response, that is exactly the kind of scenario work I take on for clients. Book a free 30-minute call and bring what the calling system expects back, and we will build the response logic correctly.

Frequently Asked Questions

What does the Make Webhook Response module do?

It overrides Make's default reply to a webhook caller, letting you control the exact HTTP status code, headers, and body returned, instead of the built-in default response of 200 "Accepted."

What status code does a Make webhook return?

Without a Webhook Response module, a successful trigger returns 200 with a body of "Accepted," and a full queue returns 400 with "Queue is full." With a Webhook Response module, you can set any valid status code your logic actually determines is appropriate.

Can Make return JSON from a webhook?

Yes. Build the response data with a JSON module, map it into the Webhook Response module's Body field, and add a Content-Type: application/json header so the calling system correctly interprets the response as JSON rather than plain text.

Where should I put Webhook Response?

Wherever in the scenario you want the caller to actually receive their reply, since it responds at that point in execution, not automatically at the end. For branching scenarios, place a response module on each relevant route so each can return appropriately different information.

Why is my Make webhook timing out?

Usually because no Webhook Response module fires before the calling system's own timeout is reached, either due to slow processing ahead of the response module or the response module being placed too late in a long-running scenario.

Can I return an error from a Make webhook?

Yes, route your scenario's failure or invalid-input logic to its own Webhook Response module set with an appropriate error status code and an explanatory body, rather than letting every request receive the same default success response regardless of actual outcome.

If you would rather have this built than build it, I take on Make.com scenario architecture work through Fiverr.