B2B headless commerce means the storefront your buyers use is built separately from the commerce system behind it. The two talk through an API (a way for software to request data and actions). You get a custom buying experience and can keep a compatible commerce platform, but you take on building and maintaining that storefront yourself (Shopify Dev Docs).
This guide is for owners and e-commerce, sales and operations leads at manufacturers, distributors, wholesalers and brands adding B2B sales. The decision starts with one question: what do your buyers need to do that a well-configured store cannot? If you want help mapping how your buyers order before you decide, our B2B commerce agency team can work through it with you.
Platform storefront or headless: compare the work
"Headless" describes how the storefront connects to the commerce engine. It says nothing about which B2B features you get. Salesforce's implementation guide, for example, treats sign-in, pricing, cart, checkout and orders as separate steps a headless storefront must support through APIs, with the commerce backend supplying the functions (Salesforce Developers).
| Question | Platform storefront | Headless storefront |
|---|---|---|
| Where does the interface come from? | The platform's themes and page tools | A separate application your team builds |
| How do you change it? | Configure settings or customize the theme | Develop and test the interface and its API connections |
| Who it suits | Teams whose buying process fits the platform's tools | Teams with a specific interface need and a budget for ongoing development |
| Who should avoid it | Teams whose essential workflows the platform cannot support | Teams whose needs are met through configuration, or who have no one to maintain a custom storefront |
| What to check | Features, integrations, setup scope | All of that, plus whether every step is available through the APIs |
There is also a middle option. A platform storefront can still be customized and integrated. Shopify describes theme customization as a step between a standard theme and going fully headless (Shopify).
It does not have to be all or nothing either. You can keep the platform storefront for some buying journeys and use headless for others, if your platform supports both.
What this means for you: compare working buyer journeys, not architecture labels.
When headless commerce for B2B is worth the work
What headless can give you, when the need is real:
- • Faster storefront changes. Your team can change the buyer experience without waiting on backend releases.
- • Several storefronts from one backend. Separate portals for dealers, distributors and direct accounts, or one per region, sharing the same catalog and orders.
- • Freedom to add specialist tools, such as a stronger B2B search engine, through APIs instead of the platform's built-in option.
Headless earns its place when the interface you need goes beyond what your platform supports. For example, dealers might need to find replacement parts by clicking an equipment diagram. Or your reps might need a different ordering screen from the one purchasing teams use. Write down that interaction and ask vendors to show how they would deliver it.
Check you are ready, too. OroCommerce warns that headless is a poor fit when basic digitization is unfinished or you do not have the staff to run it, and lists API management, clear ownership and cross-team coordination as prerequisites (OroCommerce).
Then ask how often it will change. An ordering tool you revise often needs a team that can release changes, test them and fix a broken connection quickly. A specialized interface with no maintenance budget is not a finished plan.
Headless is a weak choice when what you need is standard account pricing, restricted catalogs or a cleaner reorder screen that your platform already offers. It is also the wrong first move when the real problem is bad product data or an unreliable connection to your ERP, the system that holds stock and orders (Oracle). A new storefront does not fix the data behind it.
Define your buying requirements first with our B2B e-commerce features checklist, then test a B2B e-commerce platform against them. For one platform's options, see our BigCommerce B2B review.
What this means for you: write down the specific limitation that makes custom development necessary. If you cannot, you probably do not need headless.
How headless B2B e-commerce carries an account through an order
A nice product page in a demo is only the start. Ask the builder to take one buyer through a full order using your account rules, and name who owns each step:
- 1. Identify the buyer and company. Sign-in confirms who the person is. Your account owner decides which company locations they can buy for.
- 2. Show the right catalog and prices. Sales owns the pricing rules. The technical team shows which system supplies them and how the storefront asks for the right account's prices.
- 3. Build the cart under the same rules. Check quantities, restricted items and prices again when the buyer switches location. Someone must own the error messages.
- 4. Run the right checkout. Finance confirms the allowed payment terms. If orders need approval, decide who approves and how the buyer sees progress.
- 5. Hand the order to operations. Decide which system receives it, what confirmation the buyer sees, and who investigates an order that never arrives.
None of this comes automatically with headless. In Shopify's documented B2B flow, developers have to pass the signed-in customer's access token and company location to get the right prices, and set the buyer's identity on the cart. It also only works with Shopify's newer customer accounts on a plan that supports B2B (Shopify Dev Docs). Approvals are another separate piece: Adobe's purchase order API works only when its B2B extension is installed and purchase orders are switched on for that company (Adobe Developer).
What this means for you: confirm your account rules hold at every step from sign-in to the warehouse.
Three ways to adopt headless
You do not have to replace everything at once. Vendors and agencies describe three paths (Alokai; Naturaily):
| Path | What changes | Suits you when |
|---|---|---|
| Full replatforming | Replaces the commerce stack | Your current platform is end-of-life or blocks growth |
| Frontend-first | New storefront; the backend is kept at first | You want buyer-facing gains and to keep backend investments |
| Selective (hybrid) | Modernizes chosen components gradually, such as search, CMS or the buyer portal | Your ERP and processes are complex and you want to move carefully |
Phased routes can reduce migration risk. How long any route takes depends on scope.
Who does the work also changes. You will typically need the platform and tool vendors, a development partner, and someone in-house who owns the roadmap and decisions.
What this means for you: start with the smallest change that solves the buyer problem you named.
Watch your search visibility
Headless does not hurt SEO by itself, but a poorly built JavaScript storefront can. Use server-side rendering or prerendering for public pages where practical, and verify what Google can render (Google Search Central). Following Naturaily's checklist, preserve redirects, canonical tags, sitemaps, internal links and product URLs; test structured data, faceted navigation and Core Web Vitals (Naturaily). Keep account pages and negotiated prices behind authentication.
What this means for you: make SEO part of the acceptance tests, not a fix after launch, because B2B buyers still find products through search.
Test the awkward cases before you build more
Example: a parts distributor wants a diagram-based dealer portal. A buyer picks a machine, adds compatible parts, then switches from one branch to another before ordering. The prototype should show the right products and prices after the switch, keep the valid items in the cart, and explain anything that changed. This is an invented scenario to test with, not a client result.
Then add failure tests. What happens when the pricing service does not respond? Can operations spot an order that failed to reach the ERP? Who tells the customer whether it is safe to try again?
Ask about caching, which stores responses so pages load faster. Shopify warns that caching personalized data in a shared way can show one customer's information to another. In its Hydrogen framework, you disable caching of personalized API responses and prevent shared caching of pages that contain them (Shopify Dev Docs).
Ask too about notifications between systems. commercetools documents that these can arrive late, more than once, or out of order (commercetools). Your builder needs a plan to catch duplicates, retry failed handoffs and check records match across systems.
What this means for you: approve how the store recovers from failures, not just how it looks when everything works.
Budget for the work after launch
The platform subscription is only part of the cost. For a rough sense of scale, Naturaily, an agency, publishes these illustrative implementation ranges (one agency's figures, not quotes; recurring licensing, infrastructure and support are separate): a unified, non-headless platform such as Shopify Plus B2B or BigCommerce B2B Edition at $20,000 to $62,000 (a comparison baseline); a hybrid headless build at $62,000 to $150,000; a fully composable stack at $150,000 to $375,000 or more (Naturaily). Your scope can land outside these. Shopify's own B2B headless guidance lists ongoing developer support, API changes, and extra security and testing work as things to plan for (Shopify). Ask for these in every proposal:
| Cost or responsibility | What to get in writing |
|---|---|
| Initial build | Storefront, account flows, integrations, data preparation and testing in scope |
| Recurring services | Commerce subscription, hosting, search or content tools, monitoring, support |
| Maintenance | Who handles security fixes, browser changes and API updates, and support hours |
| Everyday changes | Who updates pages, promotions, catalogs and account rules without a developer |
| Leaving the provider | Access to source code, documentation and customer records, and the handover process |
Ask the builder to show how your staff will edit a page or change a pricing rule. Count your own team's time too, even if an agency maintains the code.
What this means for you: compare proposals on the same ongoing responsibilities, not just the build price.
Decide with a small prototype
Before you commission the full storefront, ask for a small prototype of the one interaction that justifies going headless. Include the account, pricing, cart and order steps it touches. Agree pass criteria with sales, finance and operations, using realistic data. Include mobile ordering, keyboard access and clear error messages.
A prototype shows the idea works. Before launch it still needs functional, integration, load, security and compliance testing, then a beta with real buyers (BetterCommerce), plus a rollback plan for returning buyers to the old store if the release fails.
If the platform storefront handles the same task within your requirements, keep it on the shortlist. If the custom approach earns its place, approve it with named owners and a maintenance budget. That is the real decision behind B2B headless commerce.
Before committing to a rebuild, see our B2B e-commerce agency page. Not sure where to start? Let's talk it through.
What this means for you: you have a concrete workflow and pass criteria to take to providers.
Frequently asked questions
Is a headless CMS the same as headless commerce?
No. A headless CMS (content management system) manages content such as pages and articles; Contentful is one example (Contentful). Headless commerce supplies buying functions such as pricing, carts and orders. Choosing a content tool does not give you those.
Can I keep my existing commerce platform?
Possibly, if its APIs support your full buying journey. Check the account, pricing and order steps actually work through the APIs before assuming they do.
Does headless mean building a fully custom checkout?
No. In Shopify's documented B2B flow, the custom storefront passes the cart, with the buyer's company and prices, into Shopify's B2B checkout (Shopify Dev Docs). Confirm how checkout receives the buyer's details before deciding how much to build.
Which platforms support headless B2B?
Many do, including commercetools, Elastic Path, Salesforce Commerce Cloud, Shopify, BigCommerce and OroCommerce. The question is not whether a platform offers APIs, but whether its APIs cover your account, pricing, approval and order steps.
Is headless the same as composable commerce?
No. Headless separates the storefront from the commerce engine. Composable commerce goes further and combines commerce capabilities from separate services, which adds more integration choices (Liferay). A custom storefront does not require replacing everything behind it.
