TL;DR: Connect WordPress to Zapier by POSTing your site's events to a Catch Hook URL from the Webhooks by Zapier trigger — no polling, no per-Zap connector needed.
- Create a "Webhooks by Zapier → Catch Hook" trigger and copy its URL.
- Send any WordPress or WooCommerce event to that URL as JSON — a form entry, a new order, a published post.
- Because you POST to an arbitrary HTTP endpoint, you avoid Zapier's per-task WordPress connector and keep the trigger self-hosted.
/ Overview
How do you connect WordPress to Zapier with a webhook?
The most reliable way to trigger a Zap from WordPress is a webhook: your site sends an HTTP POST to a Zapier Catch Hook URL the instant an event happens, and Zapier treats that payload as the trigger. This is push, not poll — Zapier's built-in WordPress app polls your REST API on a schedule and only sees a narrow set of events, whereas a webhook fires immediately for any action on your site. The Webhooks by Zapier trigger is available on paid Zapier plans and is the standard entry point for custom integrations.
/ Catch Hook
What is a Zapier Catch Hook URL?
When you add "Webhooks by Zapier" as a Zap's trigger and choose the Catch Hook event, Zapier generates a unique URL that looks like https://hooks.zapier.com/hooks/catch/123456/abcde/. Anything POSTed to that URL becomes an incoming trigger event. Zapier parses JSON bodies automatically, exposing each field for use in later Zap steps. You do not authenticate the request in the usual sense — the URL itself is the secret, so treat it like a credential and, if your platform supports it, add a shared-secret header your downstream steps can verify.
/ Sending events
How do you send a WordPress event to the Catch Hook?
Any code path that produces an HTTP POST works. The direct approach is a wp_remote_post() call inside a hook callback — but doing it inline blocks the request and has no retry if Zapier is briefly unreachable. The example below shows the raw version so you can see the shape of the payload.
PHP — post a WooCommerce order to a Zapier Catch Hook
add_action( 'woocommerce_order_status_completed', function( $order_id ) { $order = wc_get_order( $order_id ); wp_remote_post( 'https://hooks.zapier.com/hooks/catch/123456/abcde/', [ 'headers' => [ 'Content-Type' => 'application/json' ], 'body' => wp_json_encode( [ 'order_id' => $order_id, 'email' => $order->get_billing_email(), 'total' => $order->get_total(), ] ), ] ); } );
That works, but it is synchronous and fire-and-forget: if Zapier returns a 500 or the request times out, the event is lost. Production integrations queue the delivery and retry it, so a transient Zapier failure doesn't drop the event.
/ No-code path
How do you do this without writing code?
A no-code webhook tool turns the same connection into an admin-UI task: paste the Catch Hook URL as the endpoint, pick the WordPress trigger, capture a real example payload, map fields to the JSON shape your Zap expects, and send a test delivery. Any tool that posts to an arbitrary HTTP endpoint works here — the Catch Hook is just a URL, so the same setup targets Webhooks by Zapier, n8n, or Make. Look for queued delivery with exponential-backoff retry, plus a per-event UUID and ISO 8601 timestamp so Zapier-side steps can deduplicate.
- Create the Catch Hook. In Zapier, add a Zap, choose Webhooks by Zapier → Catch Hook, and copy the generated URL.
- Add a webhook in WordPress. In your webhook tool, create a webhook, paste the URL, and select a trigger such as
woocommerce_order_status_completedor a Contact Form 7 submission. - Map the payload. Rename and restructure fields so the JSON matches what your Zap steps read.
- Test and turn on. Send a test delivery, confirm Zapier caught it, then enable the webhook.
/ Reliability
Why not just use Zapier's built-in WordPress app?
Zapier's native WordPress and WooCommerce apps poll your REST API and cover a fixed list of triggers (new post, new order). A webhook covers any do_action on your site, fires instantly instead of on Zapier's polling interval, and — with a queue behind it — survives transient failures. It also changes the cost model: you are sending one HTTP request per event from your own server rather than leaning on a polling connector.
| Aspect | Zapier WordPress app (poll) | Raw wp_remote_post | Webhook Actions |
|---|---|---|---|
| Latency | Up to the polling interval | Instant on the event | Instant on the event |
| Trigger coverage | Fixed app trigger list | Any hook you wire up by hand | Any do_action, chosen in wp-admin |
| Delivery | Zapier pulls when it polls | Fire-and-forget — no retry | Queued, retried with backoff |
| Dedup | App-dependent | Roll your own | Per-event UUID + timestamp |
| Setup | Connect the Zapier app | Write & maintain code | No code — map fields in the UI |
| Hosting | Relies on Zapier connector | Your server | Your server |
/ Alternatives
What if you want to avoid Zapier's task fees entirely?
The same push pattern targets any automation platform. Point the webhook at an n8n webhook node or a Make scenario instead of Zapier's Catch Hook and you get comparable routing without per-task pricing — n8n in particular can be self-hosted. If you are weighing tools, the webhook plugin comparison lays out the trade-offs honestly. The connection technique never changes: WordPress event → HTTP POST → whatever catches it.