logo
Fixing WooCommerce AutoFetch Reliability: What Was Broken, What We Rebuilt

Fixing WooCommerce AutoFetch Reliability: What Was Broken, What We Rebuilt

"Auto-fetch never really worked" is one of the most common complaints about bulk-sync tools in general. When we rebuilt AutoFetch for BPS Cloud, we didn't just re-implement the same webhook idea and hope it held up better. We went looking for the specific way a webhook-based auto-update silently stops working, found it, and fixed it before it ever shipped.

Where "check the dead-letter queue" turned out to be the wrong question

Our first instinct was to check whether failed webhook deliveries were landing in a queue for review. They weren't — because there isn't one in that path. POST /webhooks/woo/{webhookToken} is a synchronous HTTP endpoint that WooCommerce calls directly the moment a product changes; there's no queue between WooCommerce and the receiver at all, unlike the job worker's sync/fetch pipeline. So "check the queue" was solving a problem that didn't exist here, and it was masking the one that did.

The real gap: zero retry logic, one shared dependency

The actual receiver code — the piece responsible for verifying the webhook, resolving a Google auth token, and writing the update into your sheet — had no retry logic anywhere in that path. A single transient 429 or 5xx from Google's OAuth token endpoint, or from the Sheets API itself, threw immediately and failed the whole request. That's a real risk, not a theoretical one: WooCommerce automatically disables a webhook after enough failed deliveries in a row. One bad blip from Google's side, at the wrong moment, could silently turn AutoFetch off — with nothing telling you it happened. You'd only find out when your sheet quietly stopped updating.

BPS Cloud menu in Google Sheets

AutoFetch runs quietly in the background from the same Automation panel — reliability there matters precisely because you're not watching it happen.

What we built instead

The webhook receiver, the scheduled sync, and the sync worker's write-back all share one underlying Sheets client. We gave that shared client real retry behavior: a transient 429 or 5xx gets retried with backoff, while an actual auth or bad-request error fails immediately instead of retrying a mistake into a longer delay. Because it's shared, fixing it once covers AutoFetch's real-time webhooks, AutoSync's scheduled runs, and manual syncs that write back to your sheet — not a patch on one code path while the others stayed exposed.

What we're still watching

This closes the "transient blip kills a webhook silently" failure mode, but we don't yet have visibility if WooCommerce does end up disabling a webhook for some other reason — today, you'd only notice because your sheet stopped updating. Surfacing a "last webhook received" timestamp is on our list if this turns out to be a real support question rather than a theoretical one.

Try it

BPS Cloud is free to install from the Google Workspace Marketplace. For how AutoFetch fits alongside scheduled AutoSync, see AutoFetch vs AutoSync, explained.

Prefer the WordPress plugin? See the Bulk Product Sync plugin page for pricing and details.