That makes the Store API one of the most valuable — and least monitored — things on a WooCommerce site.
Why Store API Failures Are Invisible to Normal Checks
A classic uptime check requests a page and confirms the server answered. But a page whose HTML arrives fine can still depend on API calls that happen after load: fetching cart contents, calculating shipping, validating the checkout. If those calls fail, the customer sees a spinner, an empty cart, or a checkout that won't advance — and the monitoring sees HTTP 200.
Worse, Store API failures are often partial:
The wrong shape, not an error. A plugin filters the products response and drops a field the frontend expects. The API still returns 200 — the storefront breaks anyway. A check that only asserts on status code sleeps through this entirely.
One endpoint, not all of them. Products responds fine while cart returns 403 because a firewall rule or security plugin started blocking POSTs with a nonce it doesn't like. Every page "works" except the one that makes money.
Intermittent under cache. An aggressive cache or CDN accidentally caches an API response containing one customer's cart or a stale nonce. Failures appear for some visitors, some of the time — the hardest class of bug to catch from a single manual test.
Slow, then broken. An API that answers in four seconds makes checkout feel frozen long before it technically fails. Latency degradation is a leading indicator worth catching on its own.
What to Actually Monitor
Cover the endpoints your storefront genuinely depends on — for most stores that's a short list:
Products (/wp-json/wc/store/v1/products) — the read path behind grids and search. Assert on status and on the presence of the fields your theme uses: prices, stock status, images.
Cart (/wp-json/wc/store/v1/cart) — the session-dependent one. This is where security plugins, nonce handling, and caching mistakes bite first.
Checkout — the endpoint the blocks checkout submits to. You can't fully exercise it with a bare HTTP check (it needs a real session and a filled cart), which is exactly why it needs the journey layer described below.
Your first-party extras. Many stores add their own endpoints — live stock badges, delivery estimators, newsletter signups. They fail more often than core, because they get less testing. If a page renders worse without it, monitor it.
For each: check the status code, response time, and the response fields the frontend consumes — not just "did it return 200."
The Two-Layer Setup That Catches Everything
API checks and browser journeys catch different failures, and the Store API needs both:
Layer 1 — direct API monitors. Scheduled requests to the endpoints above, asserting on a success status and the expected response fields. These catch the wrong-shape and blocked-endpoint failures within minutes, often before the storefront shows any visible symptom. In NorthDuty this is API monitoring — it can even suggest the endpoints by watching what your pages actually call, so the "which endpoints matter" question answers itself.
Layer 2 — a real checkout journey. A real browser adds a product, opens the cart, and completes checkout on a schedule. This is the only way to verify the session-and-nonce-dependent path end to end — the part a stateless API check can't reach. When the Store API failure is intermittent or cache-related, the journey is what catches it in the same conditions a customer hits. That's the core of WooCommerce monitoring, and you can see a monitored checkout run step-by-step, including a caught failure, on the live demo.
The layers also diagnose each other: journey failing + API monitors green points at the frontend or session handling; API monitor failing + journey (momentarily) fine tells you a break is arriving before customers feel it.
When Failures Cluster: Updates and Config Changes
Store API breakage isn't randomly distributed. It clusters around WooCommerce core updates (the Store API still evolves release to release), security/firewall plugin updates and rule changes, cache/CDN configuration edits, and permalink or site-URL changes. Two habits neutralize most of it: re-run your API monitors and checkout journey immediately after any of those changes rather than waiting for the schedule, and treat a new latency baseline after an update as a finding, not a coincidence.
A 20-Minute Starting Point
If you're setting this up today: list the API calls your storefront makes (dev tools → Network tab while browsing, carting, and checking out — or let your monitoring suggest them), add monitors for products, cart, and every first-party endpoint with field-level assertions, add one scheduled checkout journey, and route both to the channel your team actually reads. From then on, the Store API can still break — it just can't break quietly.