Shopify is retiring the REST Admin API. Here's what breaks if your integration isn't adapter-based.

Shopify marked the REST Admin API legacy as of October 1, 2024. Since then it's been sunsetting individual REST resources in waves rather than pulling the whole thing at once — the first wave, including endpoints like products/count.json, went dark in October 2025, with further resources scheduled through 2026. If an integration was built directly against REST endpoints — not behind an adapter — some part of it is either already broken or on a countdown.

What's actually being deprecated

Not everything at once. Shopify is retiring REST Admin API resources on a rolling schedule, pushing everyone toward the GraphQL Admin API as the canonical way to read and write store data going forward. New apps have been required to use GraphQL for a while now; the current phase is about migrating integrations that were built earlier, when REST was still the default recommendation.

Why this keeps catching integrations off guard

The pattern is familiar to anyone who's watched a platform API evolve: a resource gets deprecated, existing calls keep working for months without any visible error, and then one day a wave of sunsets lands and requests that worked yesterday return 404s or empty payloads. Real threads on Shopify's own community forum — developers asking why endpoints stopped responding, why apps that "hadn't changed anything" broke overnight — are exactly this pattern playing out in production.

The root cause is rarely the deprecation itself. Shopify publishes changelogs and sunset dates well in advance. The actual failure is architectural: an integration that calls REST endpoints directly, scattered across a codebase, with no single layer that knows what "a product" or "an order" looks like independent of which API version returned it.

The fix is an adapter, not a rewrite

The teams who weren't affected by the October 2025 wave weren't lucky — they'd built (or used) an adapter layer between their application code and Shopify's raw API. The application asks for product.price; the adapter decides whether that comes from a REST call or a GraphQL query, and the answer can change without the application code changing at all.

// What breaks when Shopify sunsets an endpoint:
const res = await fetch('https://store.myshopify.com/admin/api/2023-01/products/count.json');
// ^ hardcoded REST call, hardcoded API version — this is the failure mode

// What doesn't break:
import { useProducts } from 'trama-sdk';
const { products } = useProducts({ limit: 24 });
// ^ the SDK owns which Shopify API version and endpoint shape it calls.
//   When Shopify moves the goalposts, this line of application code
//   doesn't change.

This is the same principle covered in the Wix guide's section on API drift — platforms change their APIs, deliberately or not, and the fix isn't vigilance, it's an adapter layer that absorbs the change before it reaches application code.

What to actually do if you're on hardcoded REST calls

1. Audit for direct REST calls — grep the codebase for /admin/api/ URLs and note which resources they hit.
2. Check each resource against Shopify's deprecation schedule — some resources have firm sunset dates, others are merely "legacy" with no date yet.
3. Migrate to the GraphQL Admin API for anything on a confirmed sunset date, following Shopify's own migration docs field-by-field.
4. Put an adapter layer between the application and the API going forward, so the next deprecation wave is a change in one place, not a scavenger hunt across the codebase.

This is precisely the failure mode a bridge layer exists to absorb. Trama's Shopify connector already speaks GraphQL under the hood; when Shopify retires another REST resource or renames a field, that's a change inside the connector, not a breaking change in every application that uses it.