Webhooks by Zapier is a built-in Zapier tool that lets a Zap receive data from any app that can send a webhook, and send data to any app or API that accepts HTTP requests. To catch a webhook, you add a “Catch Hook” trigger, copy the unique URL Zapier gives you, and paste it into the sending app’s webhook settings. To send one, you add a webhook action such as POST, enter the destination URL and map the data you want to send.
Webhooks are how you connect Zapier to tools that don’t have a ready-made integration, or that have one missing the trigger or action you need. This guide covers both directions, how to test them, and the security habits that keep a webhook Zap from becoming a liability.
What a webhook actually is
A webhook is a message one system sends to another when something happens. Instead of Zapier asking an app “anything new?” on a schedule, the app sends the data to a URL the moment the event occurs. The message is an HTTP request, usually a POST, with a body that is commonly formatted as JSON.
That gives you two jobs:
- Receive: Zapier provides the URL and the other app sends to it. This is a trigger.
- Send: Zapier sends a request to someone else’s URL, often an API endpoint. This is an action.
Zapier’s help center lists which plans include webhooks. It is a premium feature, so check that your plan includes it before you design a workflow around it.
Catching webhooks: the trigger options
When you choose Webhooks by Zapier as a trigger, you will see three event types:
- Catch Hook: the right choice for most cases. Zapier gives you a unique URL, accepts the incoming request and splits the body into fields you can map later.
- Catch Raw Hook: returns the unparsed body plus the request headers. Use it when you need header values, such as a signature, or when the body format needs custom handling.
- Retrieve Poll: not a true webhook. Zapier checks a URL you provide on a schedule and looks for new items. Use it when the other system can’t push data but does expose a list of records.
How to set up a Catch Hook
- Create a Zap and choose Webhooks by Zapier as the trigger app.
- Choose Catch Hook as the event.
- Optionally set “Pick off a child key” if you only want one part of the incoming data, such as a nested “data” object.
- Copy the webhook URL Zapier shows you.
- Paste it into the sending app’s webhook or notification settings, and choose which events should be sent.
- Trigger a real event in the sending app, such as creating a test record.
- Back in Zapier, test the trigger and confirm the fields arrived as expected.
If nothing appears, re-send the event from the app and check that the URL was saved exactly, with no missing characters. Some apps also need you to switch the webhook on after saving it.
Behaviour worth knowing
- If the incoming request contains an array of objects, Zapier runs the Zap once per object. That is useful for batches, but surprising if you expected one run.
- A live Zap answers the sender with a standard success response that you can’t customize. If the sending app expects a specific reply, a Catch Hook is not the right receiver.
- The URL is tied to the Zap owner’s account. If a Zap is transferred to another owner, the URL can change and you will need to update it in the sending app.
- There are payload size and rate limits. Check the current numbers in Zapier’s help center before sending large or frequent payloads.
Sending webhooks: the action options
As an action, the webhook app lets you make HTTP requests to other systems. The main events are:
- POST: send new data, the most common choice for creating records through an API.
- PUT: send data that replaces or updates an existing record.
- GET: request data from a URL and use the response in later steps.
- Custom Request: full control over the method, headers and raw body, for APIs with specific requirements.
How to set up a POST action
- Add an action step and choose Webhooks by Zapier, then POST.
- Enter the destination URL from the receiving app’s API documentation.
- Choose the payload type the API expects. Most modern APIs expect JSON.
- Add data fields as key and value pairs, mapping values from earlier steps.
- Add any headers the API requires, such as a content type or an authorization header.
- Test the step and read the response Zapier shows. A successful response often includes the ID of the record created.
If the API needs a precise JSON structure, such as nested objects or arrays, the simple key and value fields may not be enough. Switch to Custom Request and write the JSON body directly, mapping values into it.
Here is an example of a JSON body you might send in a Custom Request, with mapped values shown as placeholders:
{
"contact": {
"email": "MAPPED_EMAIL",
"first_name": "MAPPED_FIRST_NAME",
"source": "website-form"
},
"tags": ["lead", "newsletter"]
}
When mapping values into a raw JSON body, watch for quotes and line breaks in the mapped data. A customer message containing a quote mark can break the JSON. Clean the value first, or let a code step build the body for you; our guide to using Python in Zapier with Code by Zapier shows how.
Testing webhooks without guesswork
Webhook problems are easier to solve when you can see exactly what was sent. A few testing habits help:
- Send a known test payload yourself: before connecting the real app, send a request to your Catch Hook URL from a command line tool so you know what to expect.
- Read Zap history: each run shows the data received and the response returned by every step.
- Test the API outside Zapier first: if a POST action fails, try the same request with an API tool. If it fails there too, the problem is the request, not Zapier.
- Use realistic data: include empty fields, long text and special characters.
A quick way to send a test payload to a Catch Hook from a terminal looks like this (replace the URL with your own):
curl -X POST "https://hooks.zapier.com/hooks/catch/YOUR_ID/YOUR_HOOK/" \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","plan":"starter","secret":"YOUR_SHARED_SECRET"}'
Security: treat the URL like a password
Anyone who has your Catch Hook URL can send data into your Zap. That is fine for low-risk data, but not for anything that creates invoices, sends emails or updates customer records. Protect webhook Zaps with these steps:
- Share the URL only with the sending app. Don’t post it in shared docs or tickets.
- Check a shared secret. Include a secret value in the payload or as a query parameter, and add a Filter step right after the trigger that only continues if the value matches.
- Verify signatures where offered. Some apps sign their webhooks. With Catch Raw Hook you can read the signature header and check it in a code step.
- Keep API keys out of plain text. Zapier’s own guidance warns against typing sensitive keys directly into webhook and code steps. For heavy API use, a private integration on Zapier’s developer platform handles authentication more safely.
- Rotate the URL if it leaks. Replace the trigger with a new one and update the sending app.
Webhooks vs other Zapier options
Before reaching for webhooks, check whether a simpler route exists:
| Situation | Better choice |
|---|---|
| The app has a Zapier integration with the trigger or action you need | Use the integration |
| The app has an integration but lacks one action | API request action from the integration, if offered, or a webhook action |
| The app can send webhooks but has no integration | Catch Hook trigger |
| You need many API calls with authentication and pagination | A private Zapier integration or custom code |
| Different payloads need different handling | Catch Hook, then branch with Zapier Paths |
Common mistakes with Webhooks by Zapier
- Sending a test event before Zapier is listening, then wondering why the trigger test is empty.
- Mapping fields from an early test payload that doesn’t match the live payload structure.
- Forgetting that an array creates one Zap run per item.
- Building JSON by hand without handling quotes in mapped text.
- Leaving a public webhook URL unprotected on a Zap that creates financial records.
When to hand webhook work to a developer
Webhooks sit at the point where no-code meets development. If you need signature verification, custom responses, retries with backoff, or a chain of API calls that depend on each other, it is usually faster and safer to hire a Zapier developer who can decide what belongs in a Zap and what belongs in code. For an example of how webhooks, APIs and Zapier fit into one plan, see our automation strategy case study connecting Monday.com, Airtable and Stripe. You can also reach us at support@growthscribe.com.
FAQ
What is the difference between Catch Hook and Catch Raw Hook?
Catch Hook gives you a webhook URL and splits the incoming data into separate fields you can map in later steps. Catch Raw Hook gives you the unparsed request body and headers, which is useful when you need to read headers or handle a format Zapier does not parse the way you want.
Is Webhooks by Zapier available on every plan?
No. Zapier treats Webhooks by Zapier as a premium feature that is not included on its free plan. Check Zapier’s current plans page for which plans include it.
Can I send a custom response back to the app that sent the webhook?
Not with the standard Catch Hook trigger. A live Zap returns a standard success response that cannot be customized, so if the sending app needs a specific reply, you will need a different setup, such as a small custom endpoint.
How do I keep my Zapier webhook URL secure?
Treat the URL like a password: share it only with the app that needs it, add a filter that checks a shared secret value in the payload, and avoid putting API keys in plain text in webhook steps. If the URL leaks, replace the trigger so the old URL stops working.


