"Do you integrate with Shopify?" is not a precise question.
Almost every OMS vendor can answer yes.
The better question is: which Shopify capabilities are supported, at what depth, and what happens when the retailer uses a feature outside the happy path?
That question matters because Shopify is not just a storefront. It is an order source, payment record, fulfillment surface, return context, inventory channel, customer system, and API platform. An OMS integration has to decide which parts it owns, mirrors, imports, exports, ignores, or explicitly does not support.
Retailers should not discover those boundaries during implementation.
The industry problem
Compatibility gaps are expensive because they are usually found late.
A retailer assumes partial fulfillment works the way their operation needs it to work. A return flow depends on a Shopify object the integration does not import yet. A discount, duty, tax, gift card, POS order, or fulfillment order field turns out to need special handling. The implementation team then has to decide whether the gap is a product issue, a configuration issue, a custom integration issue, or a process change.
That is a bad moment to learn the truth.
An OMS should publish the truth earlier.
What a compatibility matrix should cover
A useful Shopify compatibility matrix should separate the integration into domains.
Order sync should cover online orders, POS orders, customer fields, addresses, payments, discounts, taxes, duties, cancellations, edits, returns, refunds, tags, fraud signals, notes, and custom attributes.
Inventory sync should cover SKU-location availability, safety stock, reservations, return disposition, transfers, channel-specific publishing, inventory item mapping, and error recovery.
Fulfillment sync should cover fulfillment orders, split fulfillment, partial fulfillment, tracking numbers, carriers, shipment cancellation, fulfillment holds, store fulfillment, warehouse fulfillment, and fulfillment status export.
Return sync should cover return records, return line items, unverified return line items, dispositions, refund timing, restock timing, and exception handling.
Each line should have a support status.
Supported out of the box. Supported with configuration. Partially supported. Not supported. Planned. Requires custom extension.
The point is not to make the matrix look perfect. The point is to make it useful.
Why this is technical, not just marketing
Compatibility is an architecture question.
Shopify's Admin GraphQL model includes objects such as Order and FulfillmentOrder, and Shopify continues to evolve its return and fulfillment surfaces. A durable OMS integration cannot treat every Shopify field as a flat payload to mirror. It has to decide what maps to the OMS data model, what remains Shopify-owned, what is imported for reference, and what triggers an operational workflow.
That means the compatibility matrix should be owned by product and engineering, not only by marketing.
If HotWax says a Shopify capability is supported, we should be able to point to the data flow, service behavior, mapping, and test evidence behind it.
If HotWax says a capability is not supported, that should be stated clearly so the retailer can plan around it.
The grounded HotWax view
HotWax should publish compatibility around three major sync categories:
Order sync: what order data HotWax imports, what it uses operationally, and what remains informational.
Inventory sync: how HotWax derives channel-safe availability and publishes it back to Shopify.
Fulfillment sync: how HotWax exports shipment and fulfillment outcomes back to Shopify while respecting split and partial fulfillment behavior.
The matrix should also include returns because returns expose the gap between ecommerce records and operational inspection. A return line in Shopify is not automatically sellable inventory in an OMS. A returned item may need inspection, disposition, damage handling, refund coordination, and restock policy before it affects availability.
What readers should learn
The matrix should teach readers how to ask better integration questions.
Instead of asking, "Do you support returns?" ask:
Do you import return line detail?
Do you distinguish received, inspected, damaged, and sellable inventory?
Do you sync refund state separately from restock state?
Do you support Shopify return objects that are still evolving?
Do you preserve enough source identifiers to reconcile later?
That is the level of clarity a serious OMS buyer needs.
The takeaway
Publishing a Shopify compatibility matrix is not a defensive move.
It is a trust move.
Retailers move faster when they know what works, what does not, and where the boundaries are. HotWax should make those boundaries visible across order sync, inventory sync, fulfillment sync, and returns so implementation teams can plan with facts instead of assumptions.