Loading tutorials…
Loading tutorials…
Pabbly's webhook trigger is how external apps tell Pabbly something happened — Stripe payments, Typeform submissions, custom app events. This walks the production-ready pattern, not the demo.
Who this is forOperators building integrations between Pabbly and apps that push data via webhooks. If you have ever copied a Pabbly webhook URL into Stripe and watched silence, this fixes that.
What you'll need
Step 1
Create a new workflow → choose Webhook trigger → Pabbly generates a unique URL. This URL is what you give the third-party app.
Workflows → Create Workflow. In the trigger picker, search "Webhook by Pabbly." Choose "Catch Webhook."
Pabbly displays a unique webhook URL. Copy it.
In the third-party app (Stripe, Typeform, your custom backend), paste this URL as the webhook endpoint.
In Pabbly, click "Wait for Webhook Response." Pabbly listens for the first incoming request.
Trigger an event in the third-party app (test payment, sample form submission). Pabbly captures the payload as sample data.
Step 2
Confirm the captured sample data has the fields you need. Some vendors send nested JSON; navigate to the right path.
In the Webhook trigger config, view the captured sample data.
Some vendors send simple flat JSON (`{email: "..."}`); others send deeply nested (`{data: {object: {email: "..."}}}`).
For nested data, downstream nodes reference the full path: `Trigger → data → object → email`.
Test the sample shape by checking what your most common production payloads look like, not just the test event.
If the shape differs between test and production, capture a real production event and re-fetch sample data before configuring downstream actions.
Step 3
For vendors that sign payloads (Stripe, GitHub, Twilio), validate the signature in the next step using HTTP/Code action.
Most reputable vendors sign payloads. The signature appears in a header (e.g., `Stripe-Signature`).
Pabbly does not have a native signature-verification module yet (as of 2026), so use either: (a) an HTTP action calling a small validator service you host, or (b) the JavaScript code execution action if your plan supports it.
In the validator: take the raw payload + signature header + your webhook secret → compute the expected HMAC → reject if mismatch.
After the validator, add a Filter: "Continue only if signature is valid."
Without this, anyone who guesses your webhook URL can inject fake data. Skipping signature validation is a real security issue.
Step 4
Vendors retry webhooks on timeouts. Store event IDs and skip re-processing seen events.
Vendors include a unique event ID (e.g., Stripe `id: evt_xxx`).
Add a Filter using a stored event-ID list. Use Pabbly's "Data Store" (built-in key-value store) or an external Sheets/Airtable to remember recently-seen event IDs.
Logic: lookup event ID in store. If found, short-circuit. If not, append to store and continue.
Without this, every webhook retry creates duplicate records. Stripe alone retries 3-5x on failures. A 10-second workflow that times out at 9 seconds will fire 4 times.
Step 5
Use the HTTP Request action to send data from Pabbly to your own backend or to other services not natively supported.
For sending data OUT of Pabbly (not just receiving), use the HTTP Request action.
In your workflow, click "+" → search "HTTP Request by Pabbly."
Configure: method (POST/GET/PUT/DELETE), URL (your endpoint), headers (auth tokens), and body (mapped fields from earlier steps).
For JSON bodies: set Content-Type header to `application/json` and construct the body using Pabbly's JSON formatter.
Test the outbound call. Verify the destination service received the data and returned a 2xx response.
Step 6
Pabbly waits up to 30 seconds for outbound calls. For long-running endpoints, fire async or break into batches.
Pabbly HTTP Request action has a default 30-second timeout. If your endpoint takes longer, the action fails.
For long-running endpoints: redesign to be async — your endpoint should accept the request quickly and process in the background, returning a job ID for later polling.
For batch sends: use the Iterator step to break a large list into smaller chunks, each within the timeout.
For known-flaky endpoints: enable retry-on-fail in the HTTP action settings (3 retries with exponential backoff is standard).
Common mistakes
No signature validation
What goes wrong: Webhook URL leaks. Attacker injects fake payment events. Workflow creates fake customer records, sends fake confirmation emails. Cleanup is forensic.
How to avoid: Validate signatures for every webhook from a vendor that supports it. Use HTTP validator or built-in code action.
No idempotency
What goes wrong: Stripe retries a payment.succeeded webhook because Pabbly returned 200 just after a timeout. Same payment creates a second order, a second confirmation email, phantom revenue in reports.
How to avoid: Always dedupe by vendor event ID. Use Pabbly Data Store, Sheets, or Airtable with a 24-72hr TTL.
Production webhook URL exposed in screenshots
What goes wrong: Internal docs or a Slack message contains the webhook URL. URL ends up in a Google search index or a shared file. Bot scanners find it. Junk data starts flowing.
How to avoid: Treat webhook URLs like API keys. Do not share in screenshots, docs, or public channels. Combine with signature validation for defense in depth.
Outbound HTTP timeouts not handled
What goes wrong: Outbound HTTP call to your backend takes 35 seconds. Pabbly times out at 30. Action shows failed. Backend processed the request anyway — but Pabbly thinks it failed and may retry, causing duplicates.
How to avoid: Redesign slow endpoints to respond quickly + process async. Or break work into smaller batches that each fit in the timeout.
Nested JSON not navigated correctly
What goes wrong: Stripe webhook sends `{data: {object: {customer: {email}}}}`. You map `Trigger → email` which does not exist. Action fails with 'email undefined.'
How to avoid: Read the full sample data structure. For nested data, the path is `Trigger → data → object → customer → email`. Use Pabbly's data picker to navigate the tree.
Recap
Done — what's next
How to build your first Pabbly Connect workflow
Read the next tutorial
Hand it off
Webhook integrations look simple in demos and break in subtle ways in production. EverestX automation specialists handle signature validation, idempotency, and timeout patterns by default. Most teams that DIY 5+ webhook integrations end up rebuilding them with help inside a year.
See specialist rates
Use a tunneling service like ngrok or Cloudflare Tunnel to expose your local backend. Point the third-party vendor at the tunnel URL. Pabbly sees the responses just as it would in production.
Not natively. The webhook URL is tied to the trigger node. To 'rotate,' duplicate the workflow with a new trigger node (which gets a new URL), point the vendor at the new URL, leave the old workflow active for 24-48 hours to catch in-flight retries, then deactivate the old.
Sub-second on the trigger side. Pabbly receives the webhook within milliseconds of the vendor sending it. Total time to action depends on downstream complexity but is usually under 5 seconds for a 3-step workflow.
Yes, using the 'Webhook Response' action at the end of the workflow. Configure the HTTP status, headers, and body. Useful for vendors that expect a specific response shape.
Webhook trigger = Pabbly RECEIVES data from outside (passive listener). HTTP Request action = Pabbly SENDS data to outside (active caller). Both use HTTP but in opposite directions.
Pabbly Connect
You have Pabbly Connect open and the canvas is staring at you. This walks one real working workflow end-to-end — trigger, action, mapping, test, and turn-on — in under 45 minutes.
Pabbly Connect
One trigger, three or four actions. Easy to draw, easy to break in production. This walks chaining, naming, and the error scenarios that hit on day 30.
Pabbly Connect
Your workflow ran fine for weeks. Now it fails — or worse, succeeds but produces garbage. This is the diagnostic sequence specialists run to isolate root cause in 15-30 minutes.
Pabbly Connect
DIY Pabbly is great — until your workflow count climbs past 10 and you cannot remember what each one does. This is the honest framework: when the cost of self-managing exceeds the cost of a specialist.
Zapier
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.