Headless WooCommerce with Hatch

By the end of this guide you will know what Hatch Connect does with WooCommerce today, which store addresses your Astro frontend can read, how guest order lookup works, and what is not covered by Hatch’s own bridge yet.

What Hatch’s WooCommerce bridge does

When WooCommerce is active, Hatch detects it (integrations.woocommerce is true in /wp-json/hatch/v1/features) and adds a read-only product catalog for headless storefronts:

• GET /wp-json/hatch/v1/store/products
• GET /wp-json/hatch/v1/store/products/{id}
• GET /wp-json/hatch/v1/store/products/{id}/variations
• GET /wp-json/hatch/v1/store/categories
• GET /wp-json/hatch/v1/store/featured

These addresses are public, because they carry the same catalog data as your /shop page. Stock and price filtering follow WooCommerce’s own visibility settings, and page size is capped to stop huge requests.

Why not just use WooCommerce’s REST API?

WooCommerce’s built-in /wc/v3/products routes need authenticated consumer keys, which makes static builds and edge fetches harder. Their responses are also large and tied to WooCommerce internals. Hatch’s store routes give a small, stable shape that does not change when WooCommerce does.

What does not work in the bridge

• No cart, checkout or orders in Hatch’s store routes. The bridge is read-only by design, until a session and sign-in model is in place that does not expose WordPress nonces to another origin.
• No prebuilt product cards or checkout templates ship from the bridge.
• Reading WooCommerce’s own /wc/v3/ routes from the frontend still needs your own Application Password and consumer key setup.

Guest order lookup

WooCommerce’s Store API order address needs the same cart token that placed the order. A guest can lose that token on refresh or from a shared link and then see an error even with the right order key. Hatch adds GET /wp-json/hatch/v1/order/{id}?key=..., which:

1. Checks the key against the order’s own key with a timing-safe compare.
2. Returns the same shape as the Store API, so the order summary page keeps working.
3. Limits each IP to 10 lookups a minute, and each order to 10 wrong keys per 15 minutes across all IPs. Raw IPs are hashed, never stored in the options table.

Accounts and payments

If you switch on Frontend accounts (Hatch, Content), the frontend shows its login and registration pages only when WooCommerce is also active. Stripe and PayPal payment fields load on the checkout page only when you switch on that gateway in WooCommerce and add its public key.

Common problems

• A product is missing from the store routes. The routes follow WooCommerce’s own visibility settings. Check the product is published and visible in the catalog.
• A guest sees an error on the order summary page. The order key in the link must match the order. After 10 wrong keys for one order, further lookups for that order are refused for 15 minutes.
• Cart or checkout does not appear. Hatch’s store routes do not provide them. They come from WooCommerce itself.

Check it works

1. Open Hatch in wp-admin and go to the Plugins tab. WooCommerce should show as detected.
2. Open /wp-json/hatch/v1/store/products in a browser. You should see your published products.
3. If you get a 404, fix permalinks first: WordPress REST API 404 and permalinks.

What to do next

• Hatch endpoints reference
• Privacy and third-party services
• Security hardening
• How headless WordPress with Astro works