Keeping an app's catalog in sync with WooCommerce

By Abdalla Kamesh · Updated October 16, 2026 · Published September 23, 2026 · 5 min read

The worst bug a store app can have is not a crash. It is showing a price that is not the price.

A customer who sees $39 in the app and $49 at checkout does not conclude that your sync is stale. They conclude that you tried something. That is why catalog sync deserves more attention than it usually gets — and why “how does it stay in sync?” is a better vendor question than most feature checklists.

Three ways to stay current

There are three ways an app can learn that your catalog changed.

Read it live. The app asks your store for products each time a screen loads. There is no second copy to keep in sync. The cost is that your store answers every screen, so its API has to be fast and must never be served from a stale cache.

Polling. The app, or the vendor’s backend, asks your store periodically: what changed? Simple, always a little stale, and it costs a request whether anything changed or not. If the interval is fifteen minutes, your worst-case staleness is fifteen minutes — which is fine for a description and not fine for a flash sale price.

Webhooks. Your store tells a server the moment something changes. WooCommerce ships this natively: a product update or an order change can each fire an HTTP request to a URL you register. Near-instant, and no wasted requests.

The strong setup uses live reads for what the shopper sees, and webhooks for everything that has to react to a change.

How StoreToNative does it

What the shopper sees is read live. The app reads products, prices and stock straight from your store’s public Store API (/wp-json/wc/store/v1/) when a screen loads. Edit a price in wp-admin, and the next screen that loads shows it. Sell the last one of something, and the app shows it out of stock. One small exception: the prices and stock of a variable product’s options come through StoreToNative’s server, which keeps them for up to a minute.

Webhooks keep everything else current. You connect your store with one click — you approve access in your own wp-admin, nothing to copy or paste. After the first sync, four webhooks are registered on your store: order created, order updated, product updated and product deleted. They keep three things current:

StoreToNative’s copy of your catalog, which the console uses for the app preview, category mapping and the product count.
Orders. The console’s order events and revenue numbers come from them. When an order placed in the app changes status, the shopper who placed it gets a notification (when push notifications are on).
Back-in-stock and price-drop alerts for shoppers who asked to be told.

StoreToNative does not register WooCommerce’s “product created” webhook. So a brand-new product may reach StoreToNative’s copy only at the next full sync. Shoppers see it at once, because the app reads your store live.

A floor under all of it. Every hour, StoreToNative checks for connected stores with auto-sync on (the default) that have not had a full sync for six hours, and syncs them. The console’s Sync now button runs a full sync straight away. Every successful full sync also checks the four webhooks and registers a fresh one for any that is missing or inactive.

You can see the webhooks yourself at WooCommerce → Settings → Advanced → Webhooks (their names start with “StoreToNative”), which is both reassuring and the first place to look when something is stale.

The five things that silently break sync

Sync failures are quiet, which is what makes them dangerous. The first four stop webhooks, so orders, alerts and the console fall behind. The fifth is the one shoppers see.

1. A security plugin blocking outbound requests. Hardening presets sometimes block outgoing HTTP, which stops webhooks leaving your server. Nothing errors visibly; deliveries just stop.

2. A firewall or WAF rule. Same effect from the other direction — the webhook leaves but is blocked or rate-limited in transit.

3. Webhooks quietly deactivated. WooCommerce disables a webhook after repeated delivery failures. Check the status column; anything not “Active” needs a look. StoreToNative registers a fresh webhook at its next successful full sync, but until then order notifications and alerts stop.

4. A plugin bypassing WooCommerce’s own save path. Bulk-edit tools, import scripts and some ERP integrations write directly to the database. No WooCommerce hook fires, so no webhook fires either. This is the sneakiest one, because the change is real in wp-admin and nothing tells StoreToNative about it. Its copy, the console and the alerts stay on the old data until the next full sync.

5. Caching in front of the API. A CDN or page cache that has started caching /wp-json/ responses will serve yesterday’s catalog no matter how well webhooks work. Because the app reads your Store API live, this is the cause shoppers actually see. /wp-json/ must always be excluded from page caching.

The two-minute check

Do this now, and again after any plugin update:

WooCommerce → Settings → Advanced → Webhooks. Every StoreToNative webhook should say Active.
Change something real. Edit one product’s price in wp-admin, save.
Close the app fully, open it again, and find that product. It should show the new price.
Undo the change.

Step 3 tests what shoppers see. If it fails, look at caching first (cause 5). Step 1 tests the rest. If a webhook keeps turning inactive, the block is outbound — a security plugin or a firewall.

Bulk imports: the special case

A bulk edit or a CSV import that updates 500 products fires 500 product webhooks. StoreToNative is built for that burst:

Each change is applied on its own. The webhook carries the product, so it is written straight into StoreToNative’s copy. Your store is not asked for its whole catalog again.
The counting waits for quiet. The product count and category totals are worked out again once the webhooks pause for five seconds, not once per product.
A full re-sync, when one is needed, is rate-limited. If a webhook cannot be applied directly, a full sync runs after five quiet seconds, and at most once a minute per app. If a full sync has just failed for a reason that would only repeat (a catalog too large, for example), these automatic re-syncs pause for 30 minutes; Sync now still works.
Your webhooks stay alive. If StoreToNative fails to process a delivery, it still answers your store with a success, so WooCommerce does not hold our problem against your webhooks.

What is still yours to do:

Verify a sample afterwards. Ten products, checked in the app, plus the product count in the console, tell you whether the import worked.
If your import tool writes directly to the database, no webhook fires at all. Press Sync now in the console afterwards. If you forget, the hourly check runs a full sync once your store has gone six hours without one.

That last point is the one that catches people. A silent, successful-looking import that bypassed WooCommerce’s hooks leaves StoreToNative’s copy, and the alerts built on it, on the old catalog for hours, with no error anywhere.

What “eventually consistent” means in practice

Even with everything working, there is a short window between your change and what a shopper sees. Two things fill it:

The screen already loaded. A product list shows what it fetched, and a product page opened from that list shows the same data. Pulling down to refresh the list, or a fresh start of the app, loads the new price.

Variable products. The prices and stock of a product’s options are kept on StoreToNative’s server for up to a minute.

Neither is a bug, and both matter for one specific case: the moment a sale starts. If you flip 200 prices at 9:00 and push a notification at 9:00, some early tappers may briefly see old prices. Flip the prices first, wait a few minutes, then send the notification. This is the same “publish the day before” discipline as seasonal campaigns, applied to prices instead of design.

The habits worth keeping

Check the webhook status monthly, and after every plugin update.
Exclude /wp-json/ from all page caching, permanently.
After a bulk edit through a tool that bypasses WooCommerce, press Sync now.
Flip prices before you announce them.
Spot-check five products in the app after any large catalog operation.

None of this is work you do continuously. It is a checklist you run at the moments when sync actually breaks, which are: plugin updates, imports, and security changes.

Related reading

In a StoreToNative app, prices and stock come live from your store, and webhooks keep orders, alerts and the console current — see how it works.