What is headless commerce?

Every online store has two halves. The front end is what shoppers see: pages, product photos, the cart and the checkout screens. The back end is the commerce engine: the catalog, prices, stock, customer accounts, orders, payments and tax rules.

In a traditional store the two halves are one application. The engine renders every page from a theme, so a change to the design is a change to the engine’s templates.

Headless commerce cuts that link. The storefront is its own application, the “head”, and it talks to the engine only through an API. The engine no longer draws pages. It answers questions such as “what is in this category?”, “add this item to the cart” and “place this order”.

The name sounds more dramatic than the idea. A headless store still has a storefront. The storefront is built and deployed on its own, and it can be replaced without touching the engine.

Follow one shopper through a headless store:

1. The shopper opens a product page. The storefront application loads in the browser, often from a server that has already rendered the page for speed and for search engines.
2. The storefront asks the engine’s API for the product: name, price, options, photos and stock.
3. The shopper adds the item to the cart. The storefront sends that to the engine, which keeps the cart and works out prices, discounts and tax.
4. At checkout, the storefront collects the address and payment, and the engine places the order. From there the order is handled in the admin like any other.

Two kinds of API are common. A GraphQL API lets the storefront ask for exactly the fields a page needs in one request. A REST API exposes resources such as products and orders at fixed addresses, and suits server-to-server work like syncing stock with a warehouse system.

Pages that rarely change, such as category and product pages, can be cached close to the shopper and served without asking the engine each time. The cart and checkout always ask the engine, because prices and stock must be current.

Because the engine only speaks through the API, more than one front end can use it at once: the website, an in-store register, a kiosk or a partner’s site, all reading the same products and writing to the same orders.

Neither approach is better in general. They trade control for simplicity in different places:

The add-on row is the one people miss. In a theme store, many extensions change the product page or checkout by injecting into the theme. In a headless store, an extension that only touches the engine works as before, while one that draws storefront screens needs those screens built for the headless front end.

Headless is worth it when one or more of these is true for you:

• Most of your shoppers are on phones. A storefront built as a modern web application can feel like an app: fast page changes, a cart that never reloads, and layouts designed for small screens first.
• Your design is your brand. You want pages that do not look like a template, and you want to change them without waiting on an engine upgrade.
• You sell through more than one front end. A website and an in-store register that share one catalog, one stock count and one order list.
• You publish a lot of content. Landing pages, lookbooks and campaign pages that marketing changes every week.

It is less useful for a small catalog with a standard look and no plans for other channels. There, a good theme does the job with fewer moving parts.

Ask these questions of any headless platform or agency:

• Search engines. Are pages rendered on the server, with real titles, meta descriptions and clean URLs? A storefront that renders only in the browser can index poorly.
• Checkout and payments. Which payment methods work in the headless checkout today? Ask for the list, not the roadmap.
• Product types. Can the storefront sell every product type you carry, such as products with options, bundles and digital goods?
• Editing. Can a marketer change a page without a developer? Look for a visual editor that publishes to the live storefront.
• Who runs the front end. Someone has to host, update and secure the storefront application. Find out whether that is you, an agency or the platform.
• Tracking. Can you connect your analytics and tag manager, and do cart and checkout events reach them?

A short proof of concept answers most of these. Build one category page, one product page and the checkout, and test them on a phone.

The engine costs the same either way. The difference is the storefront, which in a headless setup is a second application with its own bills:

• Building it. A custom storefront is a real software project: design, development, testing on every common phone and browser.
• Hosting it. The storefront needs servers or an edge platform, and someone watching them.
• Keeping it current. Front-end frameworks move fast. Security fixes and upgrades for the storefront are as routine as they are for the engine.
• Add-on work. Every extension that shows something to shoppers needs its storefront part built or adapted.

These costs drop sharply when the platform ships a ready storefront and runs it for you. Then you pay for design changes, not for keeping the lights on.

“Headless is only for big companies.” It used to mean building a storefront from scratch. Platforms that ship a ready headless storefront remove most of that cost.

“Headless is always faster.” Speed comes from how the storefront is built and cached, not from the word headless. A heavy headless storefront can be slower than a light theme.

“You lose easy page editing.” Only if nobody built an editor. A visual editor that writes to the headless storefront gives marketers the same control a theme editor does.