A catalogue update reaches the store, but one item keeps its old availability. The integration ran; the useful result is still missing. Shopify has marked its REST Admin API as legacy and requires new public apps submitted from 1 April to use GraphQL. For a merchant planning an integration, this is a good time to ask which everyday jobs depend on it and how the team knows they worked.
Name the jobs before choosing the plumbing
List the business tasks the connection performs: bringing in stock, updating product details, passing an order to fulfilment or returning a dispatch reference. Give each task an owner and an example that can be recognised outside a developer console. An integration is easier to commission when everybody can point to the same finished job.
Keep the announced requirement in its proper scope. Shopify’s statement concerns new public apps submitted to its App Store; it also describes continuing REST access for existing apps. Product API migration requirements deserve their own review. A blanket claim that every older integration stops on one date creates unnecessary confusion.
Agree what a complete update means
GraphQL lets a developer request a chosen set of related information. That flexibility is useful, but the store still needs a clear definition of completeness. If a stock update covers several locations, for example, decide which locations matter to the customer-facing availability and how a partial result is recognised.
Write down the identifiers shared between systems. A product name can change; the integration should still know which item it is updating. Include the ordinary messy cases in the sample data: a renamed variation, a discontinued product and an order that has already been sent once. These cases expose assumptions quickly.
Make interruptions visible
A connection needs an understandable response when a request fails or only part of a job succeeds. The operations team should be able to see what is waiting, what can be retried and what needs a person. An unexplained green status beside a stale catalogue is a poor substitute for that information.
Rehearse a retry using test data. The second attempt should leave the business record in a sensible state, with enough history to explain what happened. For an order handover, check that a repeated request does not quietly become a second shipment. Treat this as a release requirement with a named reviewer.
Switch with evidence from a small sample
Choose a manageable set of products or a test store and compare the old and proposed outcomes. Inspect the storefront and the receiving system, not just the API response. The developer can explain the technical checks while the merchant verifies the price, availability and order details a customer would recognise.
A headless commerce project needs the same care around its data boundaries. Whichever API carries the information, the important promise is that the right change reaches the right place and somebody can diagnose a missed step. Plan the migration around that promise, with a clear owner for the first live checks.
