Why Shopify moved to GraphQL

Anyone scoping a Shopify integration runs into the same fork early: two ways to talk to the same store, with different shapes, different limits and different futures.

The choice is largely settled. Shopify designated its REST Admin API as legacy in late 2024, and from 2025 new public apps have been expected to be built on GraphQL. New capability appears in GraphQL first and sometimes only. The practical position is that a new build uses GraphQL and an older integration is on a clock.

The shift, in plain terms

Not a rewrite of the data. The same orders, products and customers, reached differently.

REST gives you fixed shapes at fixed addresses. Ask for an order and you get the whole order, every field, whether you needed them or not. Need the customer as well and that is a second request. Need each line item's product detail and that is another request per product.

GraphQL lets you describe what you want. One request stating the fields you need, across related objects, returning exactly that and nothing else.

For reconciliation work the difference is stark. Building a picture of an order with its line items, discounts, taxes, transactions and customer takes a handful of round trips under REST. Under GraphQL it is one request, and the response contains no fields you have to discard.

Why it matters more than it sounds

Three consequences that change how an integration behaves in production.

Fewer requests for the same information. Round trips are the dominant cost when syncing a real store's history, and collapsing five into one is not a marginal improvement.

The limit is measured differently. REST counted requests. GraphQL prices each query by how much work it asks for, which means a small, precise query is cheap and a greedy one is expensive — you are charged for what you actually requested rather than per call. That rewards asking narrowly, and it punishes the habit of fetching everything just in case. See Shopify API rate limits and query cost.

The schema is self-describing. The API can be queried for its own structure, so tooling knows what exists and what type it is. Field changes surface at development time rather than as a surprise in production.

What gets harder

It is not a free upgrade, and pretending otherwise leads to underestimated projects.

The learning curve is real. Pagination through cursors, connections and edges, node identifiers, and errors that arrive inside a successful response rather than as a failure status. All of it is learnable and none of it is what a developer coming from REST expects.

Errors are quieter. A GraphQL request can return a status indicating success while the response body contains partial data and an errors block explaining what did not work. Code that checks only the status code will treat that as fine, and the gap will show up later as missing records.

Query cost has to be managed deliberately. A query that works on a small development store can exceed the per-query ceiling on a real catalogue. That is a design consideration during development, not a problem to discover at go-live.

Nested requests hide expense. Because asking for related data is easy, it is easy to ask for a great deal. A query walking orders, then line items, then variants, then inventory across locations is a single request that costs a great deal, and it will be throttled.

What this means if you are buying rather than building

Two questions worth asking a vendor, and neither is technical enough to need a developer present.

Which API does your Shopify integration use? An answer of REST is not disqualifying, but it means migration work sits ahead of them, and that work will happen while they are also supporting you.

How do you handle version upgrades? Shopify releases quarterly and retires older versions on a published schedule, so this is a recurring obligation rather than a one-off — see Shopify API versioning and what breaks.

The reason this is worth asking is that API migration work is invisible from outside and consumes exactly the capacity that would otherwise go into fixing your issues. See why integration depth beats feature count.

The part GraphQL does not fix

Worth stating plainly, because the technical improvement can create false confidence.

A better query language does not create data that was never captured. For a Malaysian merchant, the fee and settlement fields on a transaction remain empty regardless of how elegantly you ask for them, because Shopify Payments is unavailable here and Shopify therefore never received the settlement detail — see what the Shopify Admin API actually returns.

So the API choice affects how efficiently you read what exists. The reconciliation problem sits somewhere else entirely, in joining Shopify's orders to a separate gateway's settlements and a bank statement — see how Shopify reconciliation actually works.

Common questions

Is the Shopify REST Admin API still usable?

It still functions, and it was designated legacy in late 2024, with new public apps expected to be built on GraphQL from 2025 onward. New capability appears in GraphQL first and in some cases only there, so an existing REST integration works today while carrying migration work that has to happen eventually.

What is the practical advantage of GraphQL for a Shopify integration?

Fewer requests for the same information, because one query can describe fields across related objects and return exactly those. Building a full order picture with line items, discounts, taxes, transactions and customer detail takes several REST round trips and one GraphQL request, which matters most when syncing a real store's transaction history.

Is GraphQL harder to build against?

In some specific ways, yes. Cursor-based pagination, node identifiers and errors returned inside an otherwise successful response are all unfamiliar to a developer coming from REST, and code that checks only the HTTP status will silently accept partial results. Query cost also has to be designed for, since a query that works on a small test store can be too expensive on a real catalogue.

Does moving to GraphQL solve Shopify reconciliation for a Malaysian store?

No. A more efficient query language does not create data Shopify never held. Because Shopify Payments is not available in Malaysia, the transaction fee and settlement fields stay empty whichever API you use, and the reconciliation still depends on joining Shopify orders to a separate payment gateway's settlement data and the bank statement.

Related: what the Shopify Admin API actually returns · what it takes to build a Shopify connector · Shopify API versioning and what breaks