Shopify is removing the automaticDiscounts query from the Admin GraphQL API in version 2027-01, and the fix is not the rename it looks like. The obvious landing spot, automaticDiscountNodes, is already deprecated itself. Teams who patch this in an afternoon will patch straight into a second dead end and do the work twice. The destination that holds is discountNodes.
What Shopify removed in API version 2027-01
The automaticDiscounts query is gone in 2027-01, along with the DiscountAutomaticConnection and DiscountAutomaticEdge types that came with it. Shopify published the removal in a changelog entry dated September 18, 2026. Version 2027-01 ships on January 1, 2027, because Shopify releases stable API versions on the first day of each quarter at 5pm UTC. Requests that still send the old query against that version come back as validation errors, not as empty results, so the failure is loud at the point it happens.
The named replacement is discountNodes with a method:automatic filter. That is a deliberate consolidation. Shopify is folding a family of discount-specific queries into one surface and letting a filter carry the distinction that used to be encoded in the query name.
automaticDiscounts vs discountNodes: what actually changes
The shape of the response changes, not just the name of the query. automaticDiscounts returned discount objects directly in its nodes array, so inline fragments sat on the connection. discountNodes returns DiscountNode objects, each carrying an id and a discount field holding a union of the concrete types: DiscountAutomaticBasic, DiscountAutomaticBxgy, DiscountAutomaticApp and the code-based variants. Every inline fragment moves one level down, from nodes into discount.
That one level is where the real cost sits. If you generate types from the schema, and any serious Shopify integration should, the generated shapes change and every call site that destructured the old result has to be touched. A find and replace will not do it safely, because the fragment spread has to move, not just get renamed.
You gain something for the trouble. discountNodes filters on method, status, discount_class, discount_type, created_at, starts_at, ends_at, market_ids, segment_ids and times_used, per the Admin API reference. Reporting code that used to pull every automatic discount and filter in application memory can push that work to the API instead. On a merchant running a few hundred live promotions across several markets, that is the difference between one paged request and a dozen.
Why automaticDiscountNodes is the wrong place to land
automaticDiscountNodes is already deprecated and points at discountNodes as well. It looks like the safe migration because its name sits closest to the query being removed and it returns a node wrapper, which is the direction the removal notice appears to be pushing. It is a trap shaped like a fix. Its reference page carries the same instruction as the removal notice: use discountNodes.
The response shape is different again, which is what makes the detour expensive rather than merely pointless. DiscountAutomaticNode exposes an automaticDiscount field rather than discount. Migrating through it means restructuring fragments twice, once into automaticDiscount and again into discount when that query collects its own removal date. Skip the hop and write the query you will still be running in 2028.
What we would change this quarter
Search for the removed names before January, and search the generated artefacts as well as the hand-written queries. Type definition files and persisted query documents hold copies of automaticDiscounts that a grep across .graphql files alone will miss, and the same is true of DiscountAutomaticConnection and DiscountAutomaticEdge, which disappear in the same version.
Then work out what your version pin is actually buying. Pinning an integration to 2026-10 does postpone this, because every stable version gets a minimum of twelve months of support with at least nine months of overlap between consecutive versions. What the pin does not do is protect you at the end of that window. When a pinned version retires, Shopify falls forward and answers using the oldest still-supported stable version, and reports which one it used in the X-Shopify-API-Version response header. Nobody on your side touched a line of code, and a query that worked yesterday starts returning validation errors. Reading that header in your client and alerting when it disagrees with the version you asked for is twenty minutes of work and the cheapest insurance in the Admin API.
The wider habit worth building on commerce integrations is to read a removal notice as a statement about direction, not as one required edit. This one says Shopify wants a single discount query with filters, not six queries named after kinds of discount. Anything in your codebase that branches on which discount query to call is written against an architecture the platform is walking away from. The same reasoning applies to the back-office automations that sync promotions into an ERP or a warehouse on a schedule. Those are the integrations nobody opens for months, which is exactly where a fall-forward break surfaces as a quiet gap in the data rather than as an alert someone sees.