Loading tutorials…
Loading tutorials…
If your app sends data and Zapier needs to receive it instantly, polling won't cut it. Webhooks by Zapier handle the instant case — once you get past the auth, payload-shape, and parsing gotchas that bite every first-timer.
Who this is forOperators connecting a tool that has no native Zapier integration, or replacing slow polling with instant triggers. Also for anyone whose Zap fires 'minutes late' and needs sub-second response time.
What you'll need
Step 1
Catch Hook = standard JSON payload, Zapier parses automatically. Catch Raw Hook = unparsed body for non-JSON or custom signatures. Retrieve Poll = Zapier polls your endpoint on a schedule.
Open Zapier → Zaps → + Create → Zap. In the trigger picker, search "Webhooks by Zapier."
You see three trigger options:
"Catch Hook" — Zapier gives you a URL. Your source POSTs JSON. Zapier parses each field and exposes them in the data picker. Use this for 90% of webhook setups.
"Catch Raw Hook" — same URL, but Zapier delivers the raw request body unparsed. Use when: the source sends non-JSON (XML, form-encoded), or when you need to verify a signature against the raw bytes.
"Retrieve Poll" — Zapier polls a URL you provide on a schedule (1-15 min). Use when: the source system cannot push webhooks and you need to pull on a schedule.
For this tutorial we will use Catch Hook.
Step 2
Choose Catch Hook → "Continue." Zapier displays a unique URL. Copy it. This URL is the destination for your source system to POST to.
Click "Continue." Zapier generates a unique URL of the form: https://hooks.zapier.com/hooks/catch/[account_id]/[hook_id]/
Copy this URL. This is the endpoint for every POST from your source system.
Treat this URL as a secret. Anyone with it can fire your Zap and consume Tasks. If it leaks, you can regenerate by removing and re-adding the trigger.
Do not test the URL by pasting into a browser — browsers send GET, not POST, and Zapier will report "no data received."
Step 3
POST a JSON body to the webhook URL. Headers: Content-Type: application/json. Body: a sample of the real payload shape.
From your source system, configure a webhook integration pointing to the URL. Most modern apps have a "test webhook" button in the webhook config UI.
If your source has no webhook UI, use curl: `curl -X POST -H "Content-Type: application/json" -d '{"email":"test@example.com","plan":"pro"}' [your_zapier_url]`
Send the POST. In Zapier, click "Test trigger." Zapier should display the received payload.
If you see "We couldn't find any data" — the POST never arrived, or the Content-Type is wrong, or the body is empty. Check your source system's outgoing webhook logs.
Critical: send a payload that matches the REAL shape of your production data. If your test sends `{"email":"x"}` but production sends `{"user":{"email":"x"}}`, your field mapping will break the moment you go live.
Step 4
Zapier exposes every parsed field from the JSON payload in the data picker. Map them to downstream action steps as you would with any other trigger.
Once the test trigger returns sample data, build downstream actions exactly like a normal Zap.
For nested JSON (e.g., `{"user":{"email":"x","profile":{"name":"y"}}}`), Zapier flattens the hierarchy in the data picker — you will see "User Email" and "User Profile Name" as top-level options.
For arrays (e.g., `{"items":[{"sku":"a"},{"sku":"b"}]}`), Zapier exposes the first item by default. To process all items, use the "Looping by Zapier" action in a separate step.
For payloads with optional fields, write the action to handle missing fields gracefully — use Filter by Zapier to skip when a required field is missing.
Step 5
If your source system signs webhooks (HMAC, shared secret, etc.), validate inside the Zap with a Code by Zapier step before running downstream actions.
If your source system sends a signature header (e.g., X-Hub-Signature, Stripe-Signature), do not skip validation.
The shape is usually: source signs `[secret + raw_body]` with HMAC-SHA256, sends the hex digest in a header. Your Zap recomputes the same digest and compares.
Add a Code by Zapier step right after the trigger. Use Python or JavaScript to recompute and compare. If mismatch, return `output = { valid: false }`.
Add a Filter by Zapier step after Code: "Only continue if valid is True."
Without signature validation, anyone with your webhook URL can fire your Zap with malicious payloads. For high-trust use cases (financial, PII), this is non-negotiable.
Step 6
Webhooks fire once. If Zapier returns 5xx or times out, most source systems do not retry. Build a buffer if data loss is unacceptable.
Zapier webhook endpoints have ~99.95% uptime. That is 4 hours of downtime per year — and during downtime, every POST is lost unless your source retries.
Most source systems (Stripe, Shopify, GitHub) retry failed webhooks with exponential backoff. Verify your source does this. If not, you need a buffer.
For high-volume or high-value webhooks, common architectures: (a) source posts to your own queue (AWS SQS, Cloudflare Queues) first, then a worker forwards to Zapier; (b) source posts to a tiny intermediate Cloudflare Worker that retries on Zapier failure.
For lower-stakes cases, accept the rare loss and add monitoring: a daily sanity check comparing source-side event count vs. Zapier run count.
Step 7
Click Publish. For the first week, monitor Zap History for received-but-failed runs and source-side webhook delivery logs for never-arrived events.
Click Publish.
Daily for 7 days: open Zap → History. Verify run count matches your source-side event count. Investigate any gap.
In your source system (Stripe, Shopify, etc.), check the webhook delivery logs. Any failed delivery attempts (4xx/5xx responses from Zapier) mean Zapier rejected the payload — usually a malformed JSON or a temporary outage.
Set up a Slack notification for the Zap's failure event: Zap → Settings → notification preferences.
After 7 clean days, drop to weekly checks. Webhook Zaps are stable once the shape is locked, but a source-system schema change can break them silently.
Common mistakes
Treating webhooks as fire-and-forget
What goes wrong: You assume every POST reaches Zapier. In reality 0.5-2% are lost to network blips, signature mismatches, or shape changes. Over a year, that is 100s of dropped events with no audit trail.
How to avoid: Cross-check source-side webhook delivery logs against Zap History weekly. For high-stakes flows, buffer through a queue or Cloudflare Worker that retries.
Sample payload that does not match production shape
What goes wrong: Your test payload was `{"email":"x"}` but production sends `{"data":{"email":"x"}}`. Field mappings are configured against the wrong shape. Every live run silently writes blank email values.
How to avoid: Always test with a real production payload — capture one from the source system's sent-webhook logs and replay it via curl. Do not invent a payload shape.
No signature verification on sensitive webhooks
What goes wrong: Your URL leaks (logs, screenshots, a misconfigured CI). An attacker fires arbitrary payloads. Bad data flows into HubSpot, Slack, or your CRM. Cleanup takes days.
How to avoid: For any webhook carrying PII, financial, or auth-related data, verify the signature in a Code by Zapier step. Treat unverified webhooks as untrusted input.
Polling when you should webhook
What goes wrong: You configured a 15-min polling trigger because the source had no obvious webhook UI. You miss events that happen between polls if the API only returns 'latest N records.' Plus, polling burns Tasks even when nothing changed.
How to avoid: Check the source app for any webhook capability — it is often hidden in developer settings, not the integration UI. Webhooks are instant and consume 0 Tasks for empty checks.
No catch-all error notification
What goes wrong: Webhook payload shape changes (source did a silent schema migration). Every run errors. You do not notice because Zap History errors do not page you by default.
How to avoid: Per-Zap setting: enable "Send email if Zap stops working." For mission-critical webhooks, also pipe Zapier errors to Slack via a secondary Zap.
Recap
Done — what's next
How to use Code by Zapier (Python and JavaScript steps)
Read the next tutorial
Hand it off
Webhooks are the highest-leverage and highest-risk surface in Zapier. One signature bug or shape change and the whole flow drops data silently for months. EverestX automation specialists own webhook design end-to-end — auth, parsing, retry, monitoring — typically $400-800 for the initial build plus $100-200/mo monitoring.
See specialist rates
Catch Hook parses the request body as JSON and exposes fields in the data picker. Catch Raw Hook gives you the unparsed body as a single string. Use Raw if you need to verify a signature against the raw bytes, or if your source sends XML, form-encoded, or other non-JSON content.
Typically under 500ms from POST received to first action firing. Compare to polling triggers which can be 1-15 minutes depending on plan tier.
The trigger itself does not. Only successful action steps consume Tasks. So a Catch Hook that filters out 90% of payloads before any action runs is essentially free.
Three checks in order: (1) is the URL exactly right including trailing slash? (2) is Content-Type set to application/json? (3) is the body valid JSON? Check your source system's outgoing webhook logs — they usually show Zapier's response status.
Not directly inside Zapier — the trigger always fires on receipt. To rate-limit downstream actions, use a Delay step or buffer through Zapier Tables (insert and process on a schedule).
Yes, as long as the Zap exists and is not deleted. If you delete the trigger and re-add it, you get a new URL. Avoid editing the trigger type — that also regenerates the URL and breaks every source system pointing at the old one.
Zapier
When a built-in action cannot do what you need, Code by Zapier is the escape hatch. Run Python or JavaScript inline. Handy, dangerous if abused, and the source of about 30% of advanced-Zap breakages we see.
Zapier
Default Zapier behavior on errors: fire once, fail silent, halt the Zap. Lose data. This walks through auto-replay, dedicated error Zaps, fallback paths, and the monitoring discipline that catches breaks within an hour — not after the next quarterly review.
Zapier
Your Zap was working last week. Today, Zap History shows red. This walks through the diagnostic flow specialists run — OAuth, payload shape, rate limits, schema drift — in the order that surfaces the issue fastest.
Shopify
Your Meta pixel was firing yesterday. Today, Events Manager shows zero purchases. Welcome to one of the most common Shopify-stack failures — and one of the most expensive if it goes unnoticed. Here's the diagnostic sequence.
HubSpot Marketing Hub
The HubSpot tracking code is what makes every other piece of Marketing Hub work — forms, workflows, lifecycle stages, lead scoring. Get this wrong and half of HubSpot quietly stops attributing what it should. Here's the install path most guides skip.