What headless commerce changes for a retail delivery team

Headless commerce moves responsibility out of one platform boundary and into an operating map shared by the retailer, implementation team, platform vendors and integration owners. Before delivery starts, name one accountable team for each customer journey, data contract, release and incident path. A vendor can operate infrastructure or a commerce capability; that does not make it accountable for the behaviour of the assembled service.

This is a product-neutral decision guide, not a client case study. The exact split varies by architecture and contract. The useful output is a map that names people or teams, escalation paths and acceptance evidence rather than placing a vendor logo beside a box.

Map the service before the backlog

Start with the journeys the retailer must operate: browse, search, product detail, price and promotion, stock, basket, checkout, account, fulfilment, returns and store-assisted sales. For each journey, trace the storefront, commerce service, content, identity, integration, data owner and third party involved. Salesforce's Composable Storefront architecture is one concrete example of these boundaries across a storefront application, managed runtime and CDN, commerce APIs and third-party systems. The responsibility exercise applies beyond that product.

• Storefront experience: accessibility, rendering, routing, analytics and graceful failure.
• Commerce capabilities: catalogue rules, basket, promotion, customer and order behaviour.
• Data contracts: the source and freshness of product, price, stock, customer and order data.
• Integrations: retries, reconciliation, dead letters, rate limits and vendor escalation.
• Platform operation: hosting, CDN and cache rules, identity, secrets, monitoring and capacity.
• Delivery operation: test ownership, release approval, rollback, incident command and customer communication.

Separate data ownership from display ownership

A storefront may display stock and price without owning either. Name the system of record, the transformation owner, the acceptable freshness and the customer behaviour when data is absent or contradictory. Store operations need a voice because “available in store” creates a promise for staff as well as a label for a customer. The same rule applies to promotions, fulfilment choices and returns.

Illustrative stock decision

System of record: inventory service
Storefront owner: displays availability and timestamp
Integration owner: retries updates and monitors lag
Store operations: defines reservation and substitution policy
Fallback: hide precise quantity when freshness threshold is missed
Incident lead: commerce operations on call

The example shows why “the platform owns stock” is too vague. Several teams own different decisions around one field, and the customer outcome depends on all of them.

Own the storefront-to-checkout handoff

A hosted or platform-provided checkout still has a boundary with the custom storefront. Someone must own basket transfer, customer identity, promotion consistency, return URLs, analytics continuity and the error shown when the handoff fails. Incident triage needs a first responder who can establish which side of the boundary is failing and route the issue with usable evidence.

Shopify describes the same broad split in its custom storefront guidance: the implementation team builds and manages the frontend while the platform provides commerce capabilities, with additional cost, complexity and ongoing integration resources to consider. That is a platform description, not proof that headless is right for a particular retailer.

Treat APIs and tokens as operated products

API versions, scopes, tokens and sales-channel configuration all change over time. Put version upgrades and deprecations on a named team's calendar. Assign token creation, rotation and revocation. Define who can change CDN rules and how those changes are reviewed. Shopify's Storefront API documentation documents quarterly versions, token types and channel setup; each creates operational work for the team using the API.

Release the whole journey

Independent deployment does not mean independent risk. A storefront release can depend on a new API shape, content model, promotion rule or identity setting. For every release, name the compatibility window, sequence, acceptance owner and rollback decision. Run synthetic journeys for the paths that keep the business trading, then monitor the handoffs as well as each component.

• Who approves a storefront release and who can stop it?
• Which service versions are compatible during rollout and rollback?
• Who validates price, stock, tax, payment and order creation end to end?
• Which team leads an incident spanning the storefront and commerce platform?
• What evidence must accompany a vendor escalation?

Choose the boundary deliberately

Headless can give a team control over the experience and release path, but that control creates ongoing work. The decision should follow the experience, integration and operating needs of the retailer, plus the teams available to own them. If the responsibility map has blank cells, the architecture is not ready for launch regardless of how complete the storefront looks.

Use the map during procurement, planning, acceptance and incidents. Revisit it when a vendor, API or internal team changes. For related delivery lessons that connect commerce boundaries with agent projects, read What 15 years of e-commerce delivery taught me about shipping AI agents.