Shopify's REST Admin API Has Been Legacy for Two Years and Still Has No Removal Date

Every few weeks a client forwards me the same kind of link: an article, a thread, a vendor page, all saying some version of migrate off Shopify's REST Admin API before it's too late. The client wants to know what it will cost them. And the honest first answer, most of the time, is a question back: what exactly is connected to your store?

Because when you go read what Shopify actually published, the urgency in the search results is not coming from the record. The record is short, it is public, and it contains one status change, three narrow deadlines aimed mostly at app vendors, an explicit carve-out — and, nearly two years on, no date for switching anything off.

This is that record, with the sentence-level receipts, plus the parts that genuinely do force a migration. It is written for the person who has to answer "so do we budget for this or not" and wants to be able to defend the answer.

A format note: the canonical version of this article carries an interactive routing quiz and a tickable integration inventory, neither of which survives a plain markdown feed. Below I have written out the same routing logic and the same steps as text.

The published record — and the row that does the most work

Rows 1–4 come from Shopify's Admin REST versioning documentation, the product APIs deprecation changelog and the GraphQL-only submissions changelog. Row 5 is an absence, checked in August 2026 — more on how we checked it below.

Reading those four announcements as one countdown is the mistake almost every write-up on this topic makes. They have different audiences and only two of them ever pointed at a merchant's own code.

"Legacy" is a status. "Removed" is an event.

This distinction is the whole article. Shopify's versioning doc puts the status in the plainest possible terms:

The REST Admin API is a legacy API as of October 1, 2024.

Read what that sentence does and does not do. It applies to the whole REST Admin API with no carve-out by app type, so nobody gets to claim their integration is exempt from the status. And then it stops. It names no consequence, no deadline and no removal — which is exactly why it has survived unchanged for as long as it has.

A status describes where something sits in a lifecycle. An event has a date attached and something stops working on it. Shopify assigned the status. It has not announced the event.

What we looked for and did not find

An absence is a weaker claim than a fact, so here is the reading behind it, done in August 2026. The pages: the Admin REST versioning doc, the REST Admin API landing page, the changelog entry on the new GraphQL product APIs, the general API versioning page, the deprecated API calls reference and the changelog's deprecation feed. Plus the Help Center's apps, managing apps and custom apps pages.

On those pages: no removal or shutdown date for the REST Admin API; no merchant-facing explanation of the API's status anywhere in the Help Center (two likely URLs redirect to the developer site instead); and no statement that organisations created after some date may only use GraphQL for custom apps.

What does exist is much narrower — individual deprecated calls can carry their own migration deadline, field by field, surfaced in the API response. That is a mechanism for retiring specific endpoints on their own schedules. It is not a plan to switch off an API.

We cannot say Shopify will never publish a removal date. We can say we looked where such a date would live and it is not there. When it appears, the top of this article changes.

The carve-out most coverage leaves out

In the same changelog entry that set the February and April deadlines, Shopify wrote this:

Custom apps built on REST that do not need to support more than 100 variants can continue to use the deprecated REST product APIs

Two conditions are bolted to that permission: it covers custom apps, not public ones, and it covers the product and variant endpoints specifically, not the REST Admin API as a whole. Within those bounds the arrangement is open-ended — no expiry is attached to it, and none has been published since.

The permission is real. So is its price, from the same entry: any merchant using custom apps built with those deprecated APIs will not be able to increase their variant limit past 100.

So the carve-out holds until the catalog needs it not to. At that point the migration stops being optional without any date being involved. That is the single most useful thing to tell a client: your deadline is not on Shopify's calendar, it is in your product data.

Three numbers, three different things

This area is a minefield of numbers that look like they belong together and do not.

• 100 — the threshold in the REST carve-out. Custom apps "that do not need to support more than 100 variants", and merchants on those apps cannot raise a variant limit past it.
• 2,048 — the number of variants a Shopify product can carry on the platform itself, raised from a historical limit of 100 in October 2025. That is a product limit, not an API one — though the same changelog warns that merchants whose apps are not on the in-support GraphQL product APIs may see a downgraded or broken experience above 100 variants.
• "Up to 2000 variants" — a figure the text of that changelog entry never states. It survives only inside the web address of the companion entry it links to, whose own title now reads 2048.

Three numbers about two different things, and the gap between the last two is a wrinkle in Shopify's own text rather than something you can resolve. Quote whichever one applies to the question in front of you and do not do arithmetic between them.

The only deadline that actually exists

If you want a real clock in this topic, it is not REST-specific at all. It is the versioning policy, and it applies to every Admin API client, GraphQL included.

Shopify ships a new API version at the start of each quarter. Each stable version is supported for a minimum of 12 months, with at least nine months of overlap between two consecutive stable versions. That rolling window is the genuine timetable.

What happens at the end of it is the part that surprises people:

Shopify falls forward and responds to your request with the same behaviour as the oldest supported stable version.

Nothing errors. Your integration keeps working — against slightly different rules than the ones it was written for. Which is why, in this topic, the realistic symptom is a quiet change in a familiar report rather than an outage, and why "it still works" is not evidence that a version is current.

An alert does exist, but it is late and it lives in the merchant's admin: Shopify's Help Center says a notification is shown in the Shopify admin when an app in the store uses an unsupported API.

The consequences Shopify names, and who they reach

Shopify names delisting from the App Store for a public app or sales channel that keeps calling unsupported resources after the upgrade deadline. For an app publisher that is severe. For a custom app it is not applicable at all — there is no listing to remove.

But "no listing" is not the same as "no consequence". The same versioning page says that for unsupported resources after the upgrade deadline, users are blocked from installing the app for a minimum of seven days, and they see warnings in the Shopify admin until seven days after the last detected use of unsupported resources.

Note the condition on all of it: unsupported resources after the upgrade deadline. That is a different thing from the REST carve-out, and conflating the two is how "REST apps are at risk" gets manufactured out of a versioning page.

Three deprecations this is not

Search results blur four separate stories into one, and each mix-up sends someone somewhere unproductive.

The first row is worth a second read if you run headless. There was never a REST version of the Storefront API, so a headless storefront had nothing to migrate. Advice telling you otherwise is describing a different API.

Also worth flattening a naming problem while we are here: if a handover document or invoice says private app, that is the old name for what Shopify now calls a custom app. Same thing. It matters because every boundary in this topic is drawn between public apps and custom apps.

Five triggers that turn this into a bill

Once you accept there is no removal date, the question changes shape. It stops being "when is the deadline" and becomes "what would make this urgent for us" — and that has five concrete answers, none of them a date.

Everything else is a planning decision.

What a deliberate wait looks like

Waiting is a legitimate engineering answer here. It is only a decision when three things are true, and the difference between a decision and a gap is what shows up in the retro.

1. A name. One person who owns the question. An unowned wait is indistinguishable from having forgotten about it, right up until it is not.
2. A channel. Shopify's own guidance to developers is to follow the developer changelog for breaking changes. That is where a removal date would appear. The merchant-facing signal — the admin notification — only fires once an app is already on an unsupported API, so it is a smoke alarm, not a calendar.
3. A written trigger list. The table above, plus one external event: Shopify publishing a removal date. If that happens this becomes a scheduling problem instead of a judgement call.

There is precedent for how these run: legacy customer accounts were deprecated with no sunset date announced either, and the stores that treated the announcement as the moment to plan came out ahead of the ones that waited for a date.

What it costs, and the one number anybody publishes

Exactly one public figure exists for this work, and it deserves to be quoted with its provenance attached rather than passed around as a benchmark. UK agency No7 Software published in May 2026 that migrating a legacy custom app from REST to GraphQL typically costs between £15,000 and £40,000, depending on complexity. One vendor, one complexity class, one date.

No agency page we read puts a per-complexity ladder on this work — nothing separating a nightly sync from a mid-sized custom app from a heavy continuous integration — and none attaches a timeline. We are not going to invent the missing figures. If a quote you receive lands well outside that range, the range is the weaker evidence.

The more useful part of that agency's post is where it says the money goes, because it is not the obvious place: the primary engineering expense is not rewriting queries but re-architecting the queueing system to handle calculated query costs instead of simple request counting.

That is the agency's characterisation, not Shopify's — and it tells you which integrations the big number is really about. A nightly script touching a few hundred products has no queueing system to re-architect. A continuous sync moving thousands of records does. If your migration estimate is dominated by query rewriting, either the integration is small or somebody has not looked at the throughput yet.

What to do this week

If you maintain Shopify integrations for other people, the deliverable that beats a migration quote right now is an inventory. Six steps, most of them a spreadsheet and a few messages:

1. List every system that touches Shopify data other than the theme and App Store apps the merchant installed themselves.
2. Put a name against each one — who built it, and who is on the hook today. Those are often different people. Flag every line where the honest answer is nobody.
3. Mark which ones write products and variants, and check whether any product needs more than 100 variants.
4. Ask, per integration, which Admin API version it pins and when that was last raised.
5. Ask, per integration, whether it calls REST product or variant endpoints, and whether any of its calls come back flagged with a migration deadline.
6. Record one decision per line: wait with a named watcher, fold into work already being paid for, or budget it now.

Steps 4 and 5 are the ones a merchant cannot answer alone. Shopify's API Health report "on the Partner dashboard shows the deprecated API calls your apps are making, along with documentation and timelines" — which lives in the developer's dashboard, not the store admin. If you are the developer, sending that output unprompted is a five-minute answer to a question your client has been reading scary articles about.

The bottom line

Shopify labelled the REST Admin API legacy on October 1, 2024, published narrow deadlines aimed largely at app vendors, wrote an explicit carve-out for custom apps on REST, and has not published a removal date. Unless a catalog is pushing past 100 variants, a new build is being scoped, or the pinned version is aging out, this is a planning question rather than a bill.

Which is a less exciting conclusion than "migrate now" — and considerably easier to defend when someone asks where the deadline is written down.

---

The full version of this article, with the routing quiz and the tickable inventory, is on our site: Shopify REST API to GraphQL: Do You Need to Pay Now?

Disclosure: this article was created with the help of AI.