Shopify Global Catalog API migration has a firm deadline: November 2, 2026. If an app your business depends on still calls the Global Catalog REST API, it needs to move to Global Catalog MCP before that service stops serving traffic. The useful question is whether anything you operate depends on the retiring endpoint. Here’s how we’d establish that, scope the work and test the replacement without turning a specific API change into an unnecessary rebuild.
What the Shopify Global Catalog API migration affects
Shopify’s October 9 developer announcement says the Global Catalog REST API, deprecated in April 2026, stops serving traffic on November 2. Shopify identifies Global Catalog MCP, which implements the Universal Commerce Protocol, or UCP, as the replacement. The cutoff also appears in the current developer changelog.
This notice concerns the Global Catalog REST API. It is not an announcement that every Shopify REST integration will stop working on November 2. That distinction matters when you brief an agency or app vendor. A broad request to “migrate our Shopify APIs” could create confusion and waste the short window available.
The affected audience is developers and businesses whose apps call this particular API. A merchant with no such dependency has no migration to perform because of this notice. A merchant whose customer-facing discovery experience relies on an affected app needs an answer from its owner now.
Our view: treat this as a dependency audit with a possible migration attached. Don’t start with a development estimate. Start with evidence that you’re exposed.
Find out whether your store has a dependency
Ask the people responsible for your custom integrations to inspect code and runtime traffic. An installed-app list is a useful starting point, but it won’t necessarily reveal an external service or a prototype someone moved into production.
Give each owner a tightly worded question: “Does any production service, scheduled job or live experiment call Shopify’s Global Catalog REST API?” Ask them to distinguish it from other Shopify APIs.
- Custom applications: Check source repositories, configuration and deployment records for references to the retiring service.
- Third-party tools: Request written confirmation from the vendor about exposure and, where relevant, its migration schedule.
- Experiments: Include product-discovery demonstrations and agent integrations that customers or staff still use.
- Scheduled workloads: Review enough history to catch infrequent jobs. A quiet afternoon in the logs doesn’t prove a dependency is unused.
For every confirmed dependency, record its owner, purpose and production location. Add the last observed request and the consequence of failure. “Customers lose a product recommendation panel” and “an internal experiment stops refreshing” deserve different priorities.
Keep an evidence-backed “not affected” list too. It prevents the same question from circulating for the next fortnight.
Scope the Shopify Global Catalog API migration around behaviour
Shopify names Global Catalog MCP as the replacement. That does not establish that the work consists of swapping a URL. The announcement alone doesn’t specify everything your implementation will need.
Your developer should verify the replacement’s current access requirements and supported operations against the application’s needs. Review request construction, response handling and failure behaviour explicitly. Don’t assume familiar REST patterns transfer unchanged.
Write down the existing contract
Before changing code, describe what the integration does today in terms a merchant can check. For example: a customer submits a product query, the app retrieves matching products, and the interface presents an offer that links to the intended destination.
That is an illustrative workflow, not a statement about every Catalog integration. Your contract might involve a background process instead. The point is to document observable behaviour rather than preserve implementation details nobody needs.
Capture representative inputs and expected outcomes. Include a query that returns nothing and products with multiple variants. Decide which fields the app must have to function and which it can omit without misleading anyone.
Separate necessary work from tempting additions
A deadline migration is a poor place to add a new recommendation strategy. Preserve the required behaviour first. Put optional improvements into a separate release unless the replacement makes them necessary.
We’d also put provider-specific calls behind a small adapter where practical. That lets the rest of the app consume a stable internal format. It adds some work now, so skip elaborate abstraction for a disposable experiment. For a maintained production service, the isolation is usually worth considering.
Use the price update as a regression test
A separate October 9 change makes price handling especially relevant. Shopify’s Catalog API update says a merchant’s compare-at price can now appear as the optional variant field list_price. The existing price field does not change.
Shopify says list_price uses the same Price object as price, with an amount in minor units and a currency. Products also return list_price_range, which contains the lowest and highest list prices across their variants. The field belongs to UCP catalog specification version 2026-08-25.
The merchant-facing announcement explains that Shopify now shares compare-at prices with AI shopping agents through Shopify Catalog. Merchants can review the sharing control in admin under the “Compare-at” section. Previously, agents reading Catalog saw the current price without the storefront’s markdown comparison.
For merchants, this is a reason to inspect the reference prices you publish. For developers, it is a useful regression case during migration. It is a separate update, and Shopify says no action is required for the new field itself. Don’t confuse that with the mandatory retirement deadline.
- Missing list price: The app should work when the optional field is absent. Absence alone does not prove the product has no storefront markdown.
- Money formatting: Interpret minor units correctly for the currency. Do not apply a universal decimal conversion without checking currency rules.
- Variant matching: Calculate any displayed saving from the current price and list price of the same variant, in the same currency.
- Product ranges: Don’t pair unrelated range endpoints to manufacture a discount claim that no individual variant supports.
As an illustrative test, a variant priced at SEK 800 with a SEK 1,000 compare-at price has a 20% markdown. A different variant’s reference price cannot serve as the denominator for that calculation. Also, a published compare-at value does not by itself establish that a promotional claim complies with local pricing rules.
Build a cutover plan that survives November 2
As of October 11, the deadline is just over three weeks away. That allows time for a controlled migration if you identify the owner quickly. It leaves little room for an unowned dependency discovered at the end of the month.
The following dates are our recommended working schedule, not additional Shopify deadlines.
By October 14: finish the dependency check
Confirm affected services and assign one accountable owner to each. If a vendor cannot yet confirm whether it uses the retiring API, keep the dependency marked unresolved. Silence is not evidence that it’s safe.
By October 21: demonstrate the replacement
Run the replacement through representative workflows in a non-production environment. Compare business outcomes rather than demanding identical response structures. Record missing capabilities early enough to choose a fallback.
By October 28: move production traffic
Leave a buffer before the shutdown. Observe request success and latency, then inspect the customer-facing result. A successful network request is not sufficient if the interface displays the wrong variant or cannot open the intended product.
Before November 2: remove the old dependency
Check live traffic and scheduled jobs again. Disable obsolete paths and update operational notes. Keep someone responsible for checking the first normal workload after the cutoff.
After the retirement, switching back to the retired API is not a viable rollback plan. Define a fallback that doesn’t need it. Depending on the application, that might mean temporarily removing an optional discovery module or directing shoppers to an existing store search experience. Avoid stale price displays as a default fallback.
What to ask an app vendor before signing off
A vendor’s “we support Shopify” answer is too broad. Ask whether its production service uses the affected API, whether the replacement is already live, and what evidence supports its readiness. Request its planned cutover date if work remains.
For a paid tool, we’d also ask what customers experience if the replacement becomes unavailable. This is a fair purchasing criterion: a useful app should have an intelligible failure mode. Small merchants shouldn’t need to reverse-engineer a vendor’s infrastructure to learn whether a product panel will disappear.
Close the task only when there is evidence: either the service does not call the retiring API, or its replacement works in production and the old calls have stopped. A completed code change without deployment leaves the risk exactly where it was.
Takeaways
- The Global Catalog REST API stops serving traffic on November 2, 2026. Confirm whether you depend on it before commissioning work.
- Migrate affected integrations to Global Catalog MCP and test the behaviour customers or staff rely on.
- Include optional compare-at prices and variant-level money handling in regression checks.
- Cut over before the deadline and choose a fallback that does not depend on the retired API.
Sources
- Compare-at prices now shared to agentic channels
- Global Catalog REST API stops serving traffic on November 2, 2026
- Catalog API now returns compare-at prices as `list_price`
- Recent changes to Shopify's platform
Want this handled for you?
We're a Shopify Premier agency and this is the work we do every day: performance, CRO, and store builds that pay for themselves. Book a free store review and we'll show you the three fixes we'd ship first.
Frequently asked questions
When does Shopify’s Global Catalog REST API stop working?
Shopify says the Global Catalog REST API stops serving traffic on November 2, 2026. It was deprecated in April 2026. Affected apps need to migrate before the cutoff.
Does every Shopify store need a Global Catalog API migration?
No. The notice affects apps that call the Global Catalog REST API. Ask your developers and app vendors to verify whether any production services or scheduled jobs use it.
What replaces Shopify’s Global Catalog REST API?
Shopify identifies Global Catalog MCP, which implements the Universal Commerce Protocol, as the replacement. Developers should check its current requirements and supported operations rather than assume the migration is a URL change.
What does list_price mean in Shopify Catalog?
list_price is an optional variant field for a merchant’s compare-at price. It uses a Price object with an amount in minor units and a currency. The existing price field remains unchanged.
Can an app roll back to the old Global Catalog REST API after November 2?
That is not a viable fallback once the API stops serving traffic. Plan a degraded experience or another supported path that does not depend on the retired service.
