WooCommerce to Zapier Not Triggering? Check These 5 Things

Paulo Henrique — Fri, 13 Nov 2026 16:44:38 +0000

Disclosure: I'm building Webhook Disable Monitor, a free WooCommerce plugin in pre-release (not published, nothing for sale). It is only relevant to check #1 and I mention it there. The other four checks have nothing to do with it.

You placed an order, the Zap didn't run, and Zapier says it received nothing. Below are five things worth checking, all documented by WooCommerce or the Zapier extension. Checks 1, 2 and 5 are done in your WordPress admin. Checks 3 and 4 (the live event test and the trigger rule) are done in Zapier, in the Zap's trigger step and its settings. They won't cover every possible cause, but they are a good place to start.

First: which setup do you have?

There are two ways covered here to send WooCommerce data to Zapier, and both use WooCommerce's built-in webhook system underneath:

A. The official "Zapier Integration for WooCommerce" extension (a paid extension sold on WooCommerce.com). According to its documentation, it "creates a webhook in WooCommerce" named WooCommerce Zapier for each Zap that uses a WooCommerce trigger. The webhook is created when you turn the Zap on and deleted when you turn it off.
B. A webhook you created yourself under WooCommerce › Settings › Advanced › Webhooks, pointing at a Zapier "Catch Hook" URL.

Checks 1, 3 and 5 apply to both. Checks 2 and 4 refer to the official extension's documentation, but the queue in check 2 is core WooCommerce behaviour, so it matters for setup B too.

1. Is the webhook still there, and is it Active?

Open WooCommerce › Settings › Advanced › Webhooks.

Disabled after repeated failures

WooCommerce disables a webhook on its own after repeated consecutive failed deliveries. The core docs say "more than five". With the default limit of 5, the code flips the status on the 7th consecutive failure, because it compares the counter before adding the new failure (class-wc-webhook.php, lines 626-640). In the code, a failure is any response outside 200–302 (the docs list 2xx, 301 and 302, and the code also accepts 300), a timeout of 60 seconds, or a connection error.

The Zapier extension docs put it more simply: "If WooCommerce encounters an error when sending data to Zapier, it will automatically disable the webhook, which stops future data from being sent to that Zap." Their fix: edit each disabled WooCommerce Zapier webhook and set it back to Active.

Three things to know before you click Active:

WooCommerce does not email you when it disables a webhook. It just changes the status.
Events that happened while it was disabled are not resent. The Zapier extension docs point to "Transferring Existing Data Using a Zap" for back-filling.
A reactivated webhook can be disabled again after a single failure, because its failure counter is not reset (open issue #70247). Fix the cause first (see check 5), then reactivate.

If you want to know the next time this happens instead of discovering it days later, that's the problem I'm building Webhook Disable Monitor for. It records each time WooCommerce disables a webhook and attempts one admin notification per episode. It doesn't reactivate webhooks, resend data, or fix cron, DNS or permission problems. It's a pre-release, not downloadable yet: pre-release details. Developers can also hook into WooCommerce's woocommerce_webhook_disabled_due_delivery_failures action themselves. If you do, test it on staging first.

Missing because the Zap was turned off (or cloned to staging)

With the official extension, "When a Zap is disabled, either because of a problem occurring or manually, the corresponding WooCommerce webhook will be removed." Zapier can also turn a Zap off by itself: the extension docs note that "If repeated errors occur, then the corresponding Zap is also disabled." The documented fix is to turn the Zap off and on again in Zapier, which recreates the webhook.

If you cloned production to staging, the docs warn that the webhook is cloned too, so "production and staging will both trigger your production Zap" until you delete the webhooks on staging. The reverse also happens: after a migration or a URL change, the webhook may point at the wrong place.

2. Is the background queue (Action Scheduler / WP-Cron) running?

WooCommerce doesn't deliver webhooks while the customer's checkout is loading. It schedules a background action called woocommerce_deliver_webhook_async (source). The Zapier extension docs say a "typical delay is between ten seconds and one minute, but the delay can be much longer in a staging/testing/development environment or sites with extremely low traffic", because Action Scheduler depends on WP-Cron.

Pending woocommerce_deliver_webhook_async actions

Go to WooCommerce › Status › Scheduled Actions, filter by Pending, and search for woocommerce_deliver_webhook_async. According to the docs, pending entries mean "data is queued to be sent to Zapier, but hasn't been sent yet". You can click Run on one to send it now. If they keep piling up, your cron isn't running. The extension docs list WP-Cron "Running and operational" as a requirement and recommend:

a test with the WP Crontrol plugin (look for "Next Run" times in the past);
or a real server cron job.

Also check the Failed filter. The docs say there's "no option to resend a failed task", and that timeouts there often mean PHP's max_execution_time is too low (they suggest at least 120 seconds).

The ALTERNATE_WP_CRON known issue

If Zapier shows rest_api_unavailable / "The Rest API is unavailable", the extension docs describe a known WooCommerce core issue that "only occurs when you use WordPress' ALTERNATE_WP_CRON feature". Their workaround is to remove that constant from wp-config.php.

3. Are you testing with a fresh, live event?

In a WordPress.org support thread from April 2026, a store owner tested a Catch Raw Hook in Zapier and got "no data". The replies explained that Zapier's test listens for new requests, and that WooCommerce sends a webhook once, when the event happens. It doesn't resend old events. The code agrees: nothing is queued for a webhook that isn't active, and there's no replay.

The reliable way to test:

In Zapier, open the trigger step and start Test trigger.
Then create a new event in WooCommerce, for example a test order with a test payment method.
Check that Zapier received it.

Also note that the first time you save an Active webhook, WooCommerce sends a ping to the delivery URL (core docs). That ping isn't an order, so don't map fields from it.

4. Does the trigger rule match what actually happens in your store?

This check happens in Zapier: open the Zap's WooCommerce trigger step and look at which trigger rule is selected. The trigger may be working perfectly and simply never matching your orders. One example the extension docs describe in detail is Order paid:

The "Order paid" trigger "will not fire for offline (deferred) payment methods such as Direct Bank Transfer (BACS), Check/Cheque, or Cash on Delivery (COD)."
The docs suggest using Order created (fires for paid and unpaid orders) or an Order status changed to… rule instead.

Also check that the trigger's topic matches the action you're performing. An order.created webhook won't fire when you edit an existing order.

5. What does the delivery log say?

Go to WooCommerce › Status › Logs and filter by the webhooks-delivery source (core docs). Each entry shows the webhook ID, topic, duration and the response code/message from Zapier. Bodies are only logged when WP_DEBUG is on.

2xx response but the Zap didn't run: the data reached Zapier, so look at the Zap itself (filters, task history, halted tasks).
4xx/5xx: the delivery failed. Repeated failures lead to check #1.
No entry at all: the event may not have been delivered yet, or at all. Go back to checks 1, 2 and 4. But a missing entry is not proof on its own: logging may be disabled or limited on your site (for example by WooCommerce's logging settings or a log retention clean-up), or the entry may be in a different log file or date. Cross-check with Scheduled Actions (check 2).

http_request_failed and timeouts

http_request_failed means your server never got a valid HTTP response. In issue #59381, users report this happening intermittently, surrounded by successful deliveries. That's a user report, and there's no public data on how common it is. Commenters there linked it to the WordPress HTTP layer and possible DNS problems on the store's server. The Zapier extension docs suggest checking server load and Zapier's status page. WooCommerce gives each delivery 60 seconds before it counts as a failure.

The WordPress user behind the webhook

With the official extension, the docs say webhooks "are tied to the WordPress user that created them". If that user is deleted or their role is downgraded, the webhooks stop working, and Zapier shows woocommerce_rest_cannot_view. The documented fix:

reconnect the WooCommerce account in Zapier;
turn each Zap off and on to recreate its webhook.

A related point: the extension revokes its REST API key after 30 days without use, which the docs call normal. Zaps that only use WooCommerce triggers keep working without it, so this explains "reconnect" prompts. It doesn't explain a trigger that stopped.

Quick checklist

Webhook present and Active? (Settings › Advanced › Webhooks)
No pile-up of Pending woocommerce_deliver_webhook_async actions? Cron running?
Tested with a new event while Zapier was listening?
Trigger rule matches the store's real behaviour (for example Order paid and offline payments)?
webhooks-delivery log shows a 2xx for that event?

Sources

Zapier Integration for WooCommerce docs: https://woocommerce.com/document/woocommerce-zapier-integration/
WooCommerce Webhooks docs: https://woocommerce.com/document/webhooks/
wc-webhook-functions.php (11.3.0): https://github.com/woocommerce/woocommerce/blob/11.3.0/plugins/woocommerce/includes/wc-webhook-functions.php
class-wc-webhook.php (11.3.0): https://github.com/woocommerce/woocommerce/blob/11.3.0/plugins/woocommerce/includes/class-wc-webhook.php
WordPress.org support thread: https://wordpress.org/support/topic/webhook-problems-used-in-zapier/
Issue #59381: https://github.com/woocommerce/woocommerce/issues/59381
Issue #70247: https://github.com/woocommerce/woocommerce/issues/70247

Sources checked on 13 November 2026. Not affiliated with or endorsed by WooCommerce, Automattic or Zapier.

DEV Community: Paulo Henrique