Shopify APIs explained: which one to use for what

Shopify has several APIs and they are not interchangeable. Picking the wrong one is the most common architectural mistake in Shopify projects — usually discovered halfway through, when something can't be read from where the code is running.

This is the pillar for API and data articles on this site.

The map

Admin API — the workhorse

Products, orders, customers, inventory, fulfilment, metafields, discounts. Anything you'd do in the admin, plus things you can't.

Authenticated with an access token obtained through OAuth. It must only ever be called from a server — the token is a credential for someone else's business, and putting it in a browser exposes the whole store.

Rate-limited by calculated query cost. Paginated by cursor. Versioned quarterly. The Admin API guide covers all three, and they shape more architecture than anything else.

Storefront API — public and safe in a browser

Products, collections, cart and checkout, exposed for customer-facing use. Its tokens are public by design and scoped to what's safe to expose.

Use it for headless storefronts, for a custom cart or live search inside an otherwise Liquid theme, or for a mobile app. Don't use it to build admin tooling — it can't see what the Admin API can, and it isn't meant to.

The choice between rendering with Liquid and rendering from this API is the fork covered in Storefront API vs Liquid.

Customer Account API — the customer's own data

Order history, addresses, and profile for an authenticated customer, with the customer as the authenticated party rather than your app.

This is what you need for account pages in a headless build. Trying to do it with the Admin API means your server authenticating as the merchant and then deciding which customer is asking — which works and is a security problem waiting to happen. The Customer Account API.

Functions and extensions aren't APIs you call

An important conceptual point that catches people out. Shopify Functions, checkout UI extensions, admin UI extensions and theme app extensions are surfaces where Shopify runs your code, not endpoints you request.

The practical consequence, and it's a big one: Functions have no network access. Everything the logic needs must already be in the input — which usually means metafields written in advance by an app.

GraphQL or REST

New development should be GraphQL. New capability lands there first, some features exist only there, and the cost-based rate limiting gives you more control than REST's per-request limit. GraphQL vs REST covers the migration and the differences that matter.

Webhooks are the other half

APIs are how you ask. Webhooks are how Shopify tells you. Any integration that has to stay in sync uses both — webhooks for immediacy, plus a periodic reconciliation query for the events that didn't arrive, because delivery is at-least-once and occasionally none-at-all.

Building on webhooks alone is the most common cause of integrations that are usually right rather than reliably right — reconciliation.

Bulk operations for volume

Anything touching the whole catalogue should use bulk operations rather than paginating. Submit a query, Shopify runs it asynchronously, you download a JSONL file. Exempt from normal rate limits, and the difference between a four-minute sync and a four-hour one.

Choosing, in one paragraph

Server-side work managing the store: Admin API. Customer-facing storefront data: Storefront API. A logged-in customer's own data: Customer Account API. A decision inside Shopify's own flow: a Function. Reacting to something that happened: a webhook plus reconciliation. Moving the whole catalogue: bulk operations.

Almost every "we can't get that data" problem is the right data behind the wrong API. Check the map before you architect around a limitation that isn't there.