Nothing changed on your side, and the sync stopped working. The error is a 404, or there is no error at all and products simply never appear. The cause is nearly always the same, and it is not the supplier.
Official print on demand integrations register REST routes inside your shop and wait for the supplier's servers to call in. Your store is the server, and someone else's machine is the client. That single design decision is the source of this entire class of failures: anything between the internet and your WordPress that can refuse a request will produce a 404, and the supplier's dashboard will just say the sync failed.
The WooCommerce REST API does not work with Plain permalinks. Every call returns 404 and nothing in the interface warns you. This costs people days.
Fix: Settings, then Permalinks, choose anything except Plain, and save. Saving alone rebuilds the rules, which sometimes fixes it even if the setting looks right.
Wordfence, iThemes, All In One WP Security, Cloudflare rules and most "hardening" snippets can block REST access from unknown clients. The fix is almost never to remove the plugin, it is one specific setting inside it.
How to check: look at what is hooked onto the REST authentication filters. A block that comes from a code snippet rather than a plugin is invisible in the plugin list, and that is the case people spend weeks on.
On cheap hosting with a single PHP process, a page that is still being built cannot serve a second request at the same time. The check appears to hang or times out, which looks exactly like a block but is not one.
How to tell it apart: a real block returns a status code quickly. Starvation hangs until the timeout. Same symptom, opposite fix: one is a setting, the other is your hosting plan.
An expired or misconfigured certificate, or a redirect loop between the www and non www versions of your domain, produces failures that look identical to blocks. The distinction matters because the fix has nothing in common.
How to check: compare a verified request with an unverified one. If only the verified one fails, it is TLS, not a firewall.
Because something else changed: a security plugin updated its defaults, your host moved you to a new server, a certificate renewed badly, or WordPress rebuilt its rewrite rules. The integration is the thing that notices, not the thing that broke.
OrderGuard is a free diagnostic plugin. It runs six checks against your own site and tells you, in plain language, which of these causes is yours. It asks for no API keys, contacts no external service, and writes nothing to your products or orders.
It also names the paid orders your supplier never collected, and adds up the money sitting in them. That one runs entirely on your own database.
Get the free pluginBecause both are partly right and neither can see the other side. The request leaves the supplier, crosses your firewall and your web server, and dies somewhere in the middle. Whoever measures the request from inside your own site can tell you where.
No, it is a test. If disabling it restores sync, turn it back on and find the specific setting, usually a REST or XML-RPC restriction. Leaving a shop unprotected to keep a sync working is a bad trade.
Yes. Every one of these causes can be measured from inside your own WordPress, with no supplier credentials and no external service.