No new stack to learn
Your team keeps the framework it already runs well, which is usually worth more than any framework feature.
YOUR STACK, SHOPIFY’S DATA
Shopify Storefront API development
The Storefront API is the GraphQL interface that lets any front end read products, collections and inventory from Shopify and drive a cart through to checkout. Building against it directly — rather than using Hydrogen — makes sense when you already have a front end stack your team knows, when the storefront is one surface among several, or when the commerce layer sits inside a larger application.
IN SHORT
- The Storefront API is Shopify’s GraphQL interface for reading catalogue and inventory and driving a cart to checkout.
- Building against it directly suits teams with an existing framework, or stores that are one surface inside a larger application.
- The API bills by query cost rather than request count, so query design decides whether the site throttles under load.
- Caching is a per-resource decision: catalogue can be stale for minutes, inventory usually cannot.
- Running a headless front end for some routes while the rest stays on Liquid is a legitimate architecture, not a half-finished migration.
What the API does and does not cover
Storefront API
A GraphQL endpoint for everything a customer-facing application needs: products, variants, collections, inventory, metafields, search, and the cart mutations that build an order. It deliberately stops at checkout — the cart is exchanged for a Shopify checkout, and payment stays on Shopify’s side of the line.
Storefront API or Hydrogen
| Hydrogen | Storefront API directly | |
|---|---|---|
| Framework choice | React, on Remix | Anything your team runs |
| Caching | Opinionated, built in | Yours to design |
| Hosting | Oxygen, included on Plus | Wherever you already deploy |
| Best when | The store is the product | The store is part of a bigger application |
| Ramp-up for your team | Learn Hydrogen’s conventions | None, if the stack is already yours |
| Escape hatch | Conventions can fight an unusual need | No conventions to fight |
How we build it
- 01
Agree the boundary
Which surfaces the custom front end owns and where Shopify takes over. Getting this line wrong is what produces the projects that rebuild checkout by accident.
- 02
Design the queries
Every page mapped to the queries it needs, scoped to the fields it renders. A page that fetches a whole collection to show six products will throttle in production; the same page with a scoped query will not.
- 03
Set the caching rules
Per resource, not per site. Product copy and collection structure tolerate minutes of staleness. Inventory and price usually tolerate none, and pretending otherwise oversells items you cannot ship.
- 04
Build cart against the API
Cart created and mutated through the Storefront API so that discounts, gift cards and market-specific pricing are calculated by Shopify rather than reimplemented in your front end.
- 05
Hand off to checkout
The cart becomes a Shopify checkout URL. Local payment methods, taxes and duties keep working because that logic never moved.
- 06
Instrument and load-test
Query cost, cache hit rate and error budget monitored from launch, since the failure mode here is gradual throttling under traffic rather than an outage you would notice.
What this buys you
Commerce inside a bigger product
When the store is one surface in a portal, marketplace or app, the API fits where a storefront framework would not.
Partial adoption
Move the routes that justify it and leave the rest on Liquid. Reversible, and much cheaper to abandon if the benefit does not appear.
Shopify still does the hard parts
Pricing, discounts, taxes, duties and checkout stay where they are correct rather than being reimplemented.
Where these builds go wrong
- Queries written to fetch everything, then filtered in the front end — the fastest route to throttling.
- Inventory cached as aggressively as product copy, so the site sells what it cannot ship.
- Cart logic reimplemented locally, which quietly breaks discounts and market pricing.
- Two half-sites with separate analytics, so nobody can tell whether the project worked.
- No plan for the script-injected apps that stop working the day the route goes live.
Related custom front-end work
The interfaces clients ask headless for are usually the ones we have already built inside Shopify: the Eat Cake Today capacity engine, where vendor lead times decide which delivery slots appear at checkout, and the Tayst bundle builder, which captures a multi-step configuration and hands it to Recharge. Neither needed a headless front end, which is the point worth taking from this page.
Who we have done this for
Clients from the roster whose work this page describes. Each links to what we actually built.
Eat Cake Today
A cake marketplace connecting customers to vendors across Malaysia. We built the back end that decides what can actually be delivered: each vendor has a daily capacity and each cake a lead time, and together they determine which dates and time slots a customer is offered at checkout.
Tayst Coffee
A guided bundle builder for a coffee subscription: the customer answers what they drink, how many drinkers there are, which roast they want and how many cups, picks their cups, and the built bundle is handed straight to Recharge.
Storefront API questions
Storefront API or Hydrogen?
Hydrogen if you have no strong existing front end preference — it gives you routing, caching and Oxygen hosting for free. The Storefront API directly if your team already runs a framework well, or if the store is part of a bigger application where Hydrogen’s conventions would fight you.
Will we hit rate limits?
Only if the query design ignores them. The Storefront API charges by query cost, so a page that fetches a whole collection to display six products will throttle under load while a properly scoped query on the same page will not. This is a design decision, not a platform limit.
Can we keep parts of the site on Liquid?
Yes, and it is often the sensible answer. Running a headless front end for the pages that need it while the rest stays on the theme limits both cost and risk — provided the URL structure and the analytics are planned as one site, not two.
What is the Shopify Storefront API?
A GraphQL API that exposes products, collections, inventory and cart operations to any client application. It is the interface that makes headless Shopify possible, and it is available on every Shopify plan rather than being a Plus-only feature.
Is the Storefront API rate limited?
Yes, by query cost rather than request count. Each query is assigned a cost based on how much data it could return, and an application draws from a replenishing bucket. Well-scoped queries rarely come close; a single over-broad query on a busy template will exhaust it.
Do we need Shopify Plus for this?
No. The Storefront API is available on standard Shopify plans. Plus matters for checkout customisation, higher API limits and Oxygen hosting, not for headless access to your catalogue.
Related
Hydrogen & Oxygen Builds
Shopify’s own React framework and hosting — the shortest path to headless that keeps you inside supported territory.
Headless CMS Integration
Editorial content in Sanity or Contentful, product data in Shopify, composed into one front end without either team blocking the other.
Liquid to Headless Migration
Moving an existing theme to a headless front end without losing URLs, SEO or the merchandising your team relies on.
NEXT STEP
Free store audit
Most stores that ask about headless have a theme or app problem instead. A senior engineer will tell you which one you have, at no cost.