WooCommerce: Store API versus order storage
Why a customer-facing API, merchant order access and HPOS are different layers—and why table existence alone cannot identify authoritative orders.
- Storefront / merchant boundary
- Supported order interface
- Selected order storage
Investigation question
Which layer should an integration inspect when a store changes order storage? WooCommerce exposes a customer-facing Store API while HPOS changes persistence behind the order model. This investigation separates public shopping operations, merchant data access and storage selection.
Observed
The Store API is documented for customer-facing products, carts and checkout. It is distinct from merchant-oriented WooCommerce REST access and does not expose arbitrary sensitive store or customer data. Public-facing does not mean every operation is an unrestricted read: cart and checkout behavior has its own documented context and protections. HPOS stores order data in purpose-built tables through WooCommerce’s CRUD model. The documentation covers compatibility and synchronization with the legacy storage arrangement. The selected authoritative storage mode matters; the existence of custom order tables alone is not a complete statement about which data a store currently uses.
Inferred
The stable integration boundary is the supported order abstraction, not a guessed table name. Reading a table directly can accidentally select a synchronized copy, an inactive storage path or an incomplete extension view. An API or CRUD operation can preserve the application’s selected storage behavior, although extension compatibility still needs verification. This also explains why storefront and back-office checks should not be combined. A working product/cart endpoint proves one customer-facing path. It does not prove that a merchant export reads all orders from the authoritative datastore.
Unknown & limitations
No merchant database, customer record, payment credential or proprietary plugin data is published here. The analysis does not assert that every extension supports HPOS or that synchronized tables are always current. It also does not establish checkout race behavior. Version-specific core and extension contracts should be checked before a storage migration; the cited source baseline is the one identified in the entry metadata.
Domain & data models
Conceptual model: customer storefront → Store API; merchant integration → authorized order interface; order interface → selected datastore. HPOS belongs at the persistence boundary. A storefront request does not select the datastore merely by using a particular REST namespace.
Workflows & state machines
Illustrative migration check: a store has both legacy and custom order tables after an upgrade. An investigator should first determine the configured authoritative mode and compatibility status, then compare a known order through the supported order interface before judging raw table counts. Zero rows in one table are not sufficient evidence that the store has no orders. A useful test set includes a recent order, an older order, a refund and an order containing extension data. Verify the operations the integration needs against the selected storage mode. Keep any real customer data out of published fixtures. This article proposes that test boundary without reproducing a merchant migration.