How to install webhooks on your website

Your contact form gets a submission. A customer pays an invoice. Someone books a call. Right now, does anything happen automatically? Or does the data just sit there until someone notices it?

A webhook is a way to make your website call out to your other tools the instant something happens. No waiting, no checking, no copy-paste. The site sends a short message to a URL you control, and whatever is listening at that URL takes over.

In this guide we'll walk through exactly how to install webhooks on your website, step by step, and cover the common platforms — plus the security and troubleshooting basics most guides skip.

What a webhook actually is

A webhook is just a URL that receives a message. When an event happens on your website (a form submission, a payment, a booking), your site sends an HTTP request — usually a POST with a small JSON payload — to that URL. Whatever is listening (a CRM, a spreadsheet, Slack, your own script) receives the message and does something with it.

The useful way to think about it: a webhook is a phone call, not a voicemail check. Most integrations poll — they check every few minutes for new data. A webhook pushes — the moment something happens, you hear about it. That's why webhooks feel instant, and why they power most real-time integrations.

Three parts make up every webhook:

1. An event — "someone submitted the form" or "an order was paid"
2. An endpoint URL — the address that receives the message
3. A payload — the data itself (name, email, order total, etc.)

That's it. The hard part is never the concept — it's knowing where to put the URL and how to test it. We'll do both.

What people use webhooks for

• Form submission → CRM (instant lead, no polling delay)
• Payment received → invoice marked paid + thank-you email sent
• New order → Slack message to the team + inventory row updated
• Booking confirmed → calendar entry created + reminder scheduled
• New customer signup → welcome sequence triggered + email list updated
• Membership/access change → access granted or revoked in another app

If you've ever used Zapier's "Catch Hook" trigger, you've already touched the receiving side of a webhook. Installing the sending side on your site is the other half.

Before you start

You need two things:

• A receiving endpoint. The easiest no-code option is a Zapier Catch Hook (Zapier gives you a URL, and you turn it into actions with dropdowns). Other options: n8n, Make, a service like Pipedream, or a small script on your own server. For this walkthrough we'll use Zapier's Catch Hook because it's free to start and works everywhere.
• A way to test. Free tools like Postman or even curl in your terminal can send a test request to your URL, so you can confirm the receiver works before your site is involved.

The 7-step walkthrough: connect your website to a webhook

This pattern works on nearly every platform — the only thing that changes is where you paste the URL.

1. Create your receiving endpoint. In Zapier, create a new Zap with the trigger Webhooks by Zapier → Catch Hook. Zapier generates a URL like https://hooks.zapier.com/hooks/catch/... — copy it. Leave the Zap in draft; you'll add actions after you confirm data is arriving.
2. Find where your platform lets you add webhooks. Every platform hides it somewhere different — the section below lists where to look for WordPress, Wix, Squarespace, Shopify, and custom sites. If your platform has no webhook field, use a form service (Formspree, Getform, Basin) that forwards submissions to your URL.
3. Paste the URL in. Add it exactly — no trailing spaces, keep the https://.
4. Add a secret if the option exists. A shared secret token, a custom header, or a query parameter (?token=...) — anything that lets the receiver know the message is really from your site. If you skip this, anyone who finds the URL can send fake events. (More in Security below.)
5. Send a test event. Most platforms have a "Send test" button. If not, trigger the real event once (submit the form yourself, or use Postman/curl to POST to your endpoint with a sample payload).
6. Verify end-to-end. Back in Zapier, check that the Catch Hook test run shows your data. Then add your actions (e.g., "Create Lead in CRM") and test again.
7. Turn on monitoring. Enable the Zap, and check the webhook logs in your platform (or the Zapier run history) after a few real events. Then forget about it — that's the point.

Where webhooks live on each major platform

• WordPress: the most flexible route. Form plugins (WPForms, Gravity Forms, Fluent Forms, Elementor Forms) all support webhooks or have a Zapier-style integration built in. For site-wide events, the WP Webhooks plugin can fire a webhook from almost anything — new post, new user, new order, form submission.
• Wix: Wix's automation tools can send HTTP requests to a webhook URL, and Wix Forms submissions can be routed through an automation. You'll find it under Automations in the Wix dashboard — build a "when form submitted" automation and point it at your endpoint.
• Squarespace: Squarespace's built-in forms don't expose a direct webhook. The standard workaround: connect the form to a service like Formspree (or Google Sheets) and let that forward to your webhook. It's one extra hop and works fine.
• Shopify: first-class webhook support: Settings → Notifications → Webhooks in the admin. Pick an event (order created, customer created, payment failure), paste your URL, and choose JSON. Shopify also signs every webhook with an HMAC signature so you can verify it's really Shopify calling — use that.
• Custom / static / hand-coded sites: a static site can't run server code, but it doesn't need to: point your form at a serverless function (Cloudflare Workers, Netlify Functions, Vercel) that forwards the POST to your webhook. If the site already has a backend, your developer adds one route that posts to the endpoint. Five minutes of code, same behavior.

Security: do this every time

Webhooks are a public URL that accepts messages — treat them with the same care as any login page.

• HTTPS only. Never send customer data over plain HTTP.
• Authenticate the sender. A shared secret header or token means a random stranger can't POST fake events into your CRM. If the provider signs payloads (Shopify HMAC, Stripe signatures), verify the signature — that's the gold standard.
• Don't log the payload. Webhook payloads often contain names, emails, and addresses. Log "received webhook, id 123, 200 OK" — not the body.
• Scope what the webhook can do. The receiving endpoint should do the minimum the event requires, not have keys to everything.

Troubleshooting: when nothing arrives

• Test the receiver first, site second. POST to your endpoint with Postman or curl. If that works, the problem is on the sending side.
• Check the URL. The most common failure is a typo, a trailing space, or http:// instead of https://.
• Check the logs. Your platform's webhook log (or Zapier's run history) will show the request, the response code, and the error.
• 401/403? The secret doesn't match, or the sender is expecting a signature you haven't verified. Check the header name and value character-for-character.
• Duplicate deliveries? Providers retry failed webhooks, and "at least once" delivery is the norm. Make your receiver idempotent — processing the same event twice should be harmless (look up the event ID before acting).
• Timeouts? The receiver must respond fast (a few seconds). If your endpoint does slow work, accept the message, return 200 immediately, and process in the background.

When NOT to use webhooks

Honesty section, because it'll save you time:

• Your platform already integrates directly — if your CRM has a native WordPress or Shopify plugin, use that first. Webhooks are for the gaps.
• You need an immediate answer — a webhook is fire-and-forget. If the workflow needs to ask something and get a response, you need a real API call instead.
• Heavy data transformation or complex logic — a chain of webhooks gets hard to follow. A tool like n8n or a small custom service keeps it manageable.
• One-off or rarely-used events — if the event happens twice a year, a webhook (and its maintenance) is overkill.

Bottom line

Installing webhooks on your website is a one-time setup that kills the "check the form and type it in" habit for good. Start with one event — form submission → your CRM or spreadsheet — confirm it end-to-end with a test, secure it with a secret, and let it run. Ten minutes of setup, and your website finally calls you when something happens instead of waiting to be asked.