Make rewrote its Shopify stock module and the scenario kept running

A breaking change in the past tense

On 11 September 2026 a note appeared in Make's help centre, tagged "Breaking change". It is short, and the tense is the first thing to notice:

To align with Shopify's latest Admin API version (2026-04), we have updated the Shopify app on Make. This update includes important changes to how inventory levels are managed, affecting the "Update an inventory level" and "Adjust an inventory level" modules.

[...]

Breaking Change in 'Update an Inventory Level': The "Compare quantity" and "Ignore compare quantity" parameters have been removed. They are replaced by a new "Change from quantity" parameter to align with Shopify's API.

• Shopify: Action required for the 'Update an Inventory Level' module, Make Help Center, published 11 September 2026, read 12 September 2026

"We have updated." Not "will update on", not "by the end of the month". The note carries no date and no grace period anywhere in its body, and the change was live when it was published. Make tagged two other notes "Breaking change" in 2026 - the monday.com and Pipedrive app transitions - and both of those carried a deadline in the title. This one does not.

The instruction that follows is what everyone who runs stock through Make will have to act on:

To prevent your scenarios from failing, you must update any scenario that uses the "Update an inventory level" module with its deprecated parameters. Scenarios using the old configuration will no longer work correctly.

• same note

"Will no longer work correctly" is doing a lot of work in that sentence. For most scenarios the likelier outcome is the opposite of a failure.

Where the change came from

Make did not invent this. Shopify announced it on 12 December 2025, in a set of changelog entries posted the same day, four of them about this field. The relevant one for this module is flagged "Breaking API Change" and "Action required", and it explains both the new field and the rule that makes it dangerous to get wrong:

We're making the changeFromQuantity field introduced in 2026-01 mandatory and removing the compareQuantity and ignoreCompareQuantity fields for the inventorySetQuantities mutation.

This is a breaking change. Note that even though the changeFromQuantity field doesn't show up as mandatory at the schema level, calling these mutations without passing in null or passing in the current actual quantity will result in an error at runtime.

• New compare and swap syntax for the inventorySetQuantities mutation, Shopify developer changelog, posted 12 December 2025, effective API version 2026-04

So on Shopify's side the field has exactly three states, and the API reference for 2026-04 spells out what each one does:

• An integer. Shopify compares it with the quantity it currently holds at that location and, if they differ, refuses the write with CHANGE_FROM_QUANTITY_STALE. This is the compare-and-swap check - the thing the old Compare quantity field did.
• null. The check is skipped and the quantity is overwritten unconditionally. This is what the old Ignore compare quantity: Yes did.
• Nothing at all. An error at runtime. In the reference's own words: "This field is mandatory: you must explicitly pass in a value, even if that value is null, or the mutation returns an error."

The old fields were deprecated in version 2026-01, which went stable on 1 January, and removed in 2026-04, stable since 1 April. Make announced its move to 2026-04 on 11 September: 273 days after Shopify's announcement, 163 days after the version went stable. By then it was not Shopify's latest version either - 2026-07 had held that title since 1 July. Make's opening line calls 2026-04 "Shopify's latest Admin API version". On the day the note was published, it was one behind.

What "no longer work correctly" most likely means

Make's note tells one group of users exactly what to do:

If you previously used "Ignore compare quantity", leave the new "Change from quantity" field empty.

• same note, step 4

That is presented as the working configuration, not as a transitional one. And under Shopify's rule above, an empty field can only work if Make sends null for it - because omitting it is an error. The same note says the Adjust module, which got the same field as a new optional input, is "not breaking and existing scenarios using this module will continue to work without modification". The Adjust module calls a mutation that Shopify put under the identical omit-and-fail rule in 2026-04. Existing Adjust scenarios have the new field empty by definition. For them to continue working, Make has to be sending null.

Put those two facts together and the picture for the Update module is this:

• If your scenario was built with "Ignore compare quantity: Yes" - the plain "set the stock to this number" configuration - the old parameter is gone, the new one is empty, Make sends null, and the write goes through exactly as it did before. No error. Nothing to see.
• If your scenario was built with "Compare quantity" mapped to the current stock - the careful configuration, the one that protected you from overwriting a sale that happened between your read and your write - the old parameter is gone, the new one is empty, Make sends null, and the write goes through. No error. And the check is no longer there.

The scenario that was doing the right thing is the one that changed. It did not break. It kept running, minus the guard.

What a missing compare-and-swap costs is not abstract. Shopify's own guide walks through it with a shoe shop:

1. Suppose that you have 100 red shoes available in one of your store locations.

2. You query the current available inventory from Shopify's APIs and determine that there are 100 units.

3. You want to adjust inventory by -10 using inventorySetQuantities.

4. Before you can do that, another process changes the inventory. 20 units are sold, so there are now 80 units.

5. You want to adjust inventory by -10 (thinking the current quantity is 100), so you set the inventory to 90 using inventorySetQuantities.

6. Result: The final available inventory value is 90, but it should be 70 (20 units lost).

• Manage inventory quantities and states, Shopify developer documentation, read 12 September 2026

Twenty units that the shop believes it has and does not. A scenario that reads a warehouse sheet and writes Shopify every fifteen minutes, on a product that sells while the scenario is between its read and its write, produces exactly this - and on this reading it has produced it on every run since 11 September if it had been relying on the compare field to catch it. The Change from quantity field is the same guard under a new name. It is just no longer filled in.

If you do fill the field in

The other half of Make's instruction is for the careful group:

Use the new "Change from quantity" parameter to perform a compare-and-swap check. If the quantity in Shopify does not match the value you provide in this field, the operation will fail.

• same note, step 3

Which is correct, and restores the guard, and has one trap that has been described on Shopify's developer forum. A quantity that has never been used for an item is reported by the query as 0, but the compare check does not accept 0 for it. A developer hit this in March on a sibling mutation that takes the same field, moving stock into a reserved quantity the item had never had, and the reply from Shopify was:

Reserved has never been used for that item, so internally there's nothing stored for it. The query shows 0, but the CAS check treats "never set" differently from "set to zero." That's why changeFromQuantity: 0 fails.

Passing null works because it skips the CAS check entirely. After that first move goes through, reserved gets initialized and integer values work going forward.

• a Shopify staff member, changeFromQuantity giving weird error, Shopify developer community, 26 March 2026

Make's module writes available, not reserved, and whether available behaves the same way the first time an item is stocked at a location is not documented anywhere we could find. The mechanism the staff member describes - "never set" treated differently from "set to zero" - is not specific to one quantity name, so a scenario that maps "current quantity from Shopify" into Change from quantity is worth testing on a product new to a location before trusting it on all of them. If it does fail there, the message from the same thread reads "The changeFromQuantity argument no longer matches the persisted quantity." It does not say the quantity was never set.

There is a second, smaller trap for anyone who bypasses the module and writes the mutation by hand in Make's "Make a GraphQL API call" module. Shopify's reference page for the 2026-04 mutation still describes the behaviour in terms of ignoreCompareQuantity and compareQuantity, and three of the four examples on that page pass compareQuantity - a field that the 2026-04 input object no longer has. Copy one of those from the page for the version you are on, and you get the field that version removed.

Is this an n8n or Zapier problem too?

Not this change, and for different reasons on each side.

n8n's Shopify node has no inventory resource at all. It offers Order and Product over REST, so anyone writing stock from n8n is doing it through the HTTP Request node with a mutation they wrote themselves - and the API version in that URL is theirs. A call against 2026-04 or later with compareQuantity in it fails at the schema, loudly, which is the better failure. The quiet one is the call that was already on a version without the guard and never had it.

Zapier never exposed the guard. Its Shopify action is "Update Inventory Quantity (with line item support)", with a switch labelled "Adjust or Set quantity?" and no compare field of any kind. Whatever Zapier sends for changeFromQuantity is internal to Zapier, and nothing about it is visible or configurable from a Zap. Which version of the Admin API the app targets is not published in Zapier's help centre. There is nothing for a user to reconfigure, and also nothing for a user to have lost.

Which group you were in

The unhelpful part first: the old value is no longer shown. Make's note says the "Compare quantity" parameter "is no longer available" in the module's configuration, so opening the scenario tells you what the module looks like now, not what it looked like on 10 September. If the scenario was documented, or whoever built it remembers, that is the fastest answer. Otherwise:

1. List the scenarios. Every one with a Shopify "Update an inventory level" module, and separately every one with "Make a GraphQL API call" pointed at Shopify. The Adjust module is on the list only for the field being new, not for anything having changed.
2. Read as much execution history as your plan still holds for each of them, looking at the Shopify module's output. Make keeps that log for seven days on Free, thirty on Core, Pro and Teams, and sixty on Enterprise, so on the day this is published the run on 11 September itself is out of reach for everyone but Enterprise. Errors mentioning changeFromQuantity in what you can see mean Make is doing something other than what is described above, and that comes first. No errors is the expected finding and answers nothing about which configuration you had.
3. Decide which behaviour you want - a question about your business, not about Make. If the warehouse system is the only thing that changes stock and Shopify only ever reflects it, null is correct and Shopify says so: opt out "if you don't care about the current quantity because you're the source of truth". If Shopify sells while the sync runs - which is what a shop is for - the guard matters, and the field wants the quantity your scenario read before it decided what to write, plus handling for the never-stocked case above.
4. Compare Shopify's stock against the source for a few fast-moving products over the weeks since 11 September. A drift that appears in that window on products that sell during sync runs is what a dropped compare-and-swap looks like from the outside. It is also the only evidence of the change most shops will ever get, because the scenario itself will have reported success every time.

A vendor's breaking change without a date

Two things about this change matter more than the mechanics.

The first is that the platform, not the vendor, is the one that broke it. Shopify announced the change three and a half months before the version went stable and nine months before Make acted, with the loudest flags its changelog has. Make absorbed that notice and released the result as a fact, on a day of its choosing, to scenarios that had been configured correctly for the API they were built against. The previous Shopify app transition, in July 2025, reached the forum as an email with, in one user's words, "less than 24 hours of notice too"; no sign of an email or in-app notice for this one reached it at all.

The second is the shape of the break. An error on the module would have been found by the first person to look at the execution log. A guard removed from a write that still succeeds shows up in a stock count, weeks later, and by then the question is which of the last few hundred writes were wrong. That is the same failure as a formula that changed meaning without changing its text and as a preview that shows one value while the execution writes another: the automation is green because it is measuring its own success, not yours.

Restoring the guard is an afternoon's work on a scenario you understand, and it has a price on it if you would rather hand it over. Establishing what the stock numbers should have been since 11 September is a separate job, and its size is set by how many products sell during a sync run, not by anything Make or Shopify changed.

Sources

• Shopify: Action required for the 'Update an Inventory Level' module - Make Help Center, published 11 September 2026 (production timestamp 09:51 UTC in the page's metadata), tagged "App updates" and "Breaking change", read 12 September 2026. The full note quoted above, including the removed and replacement parameters, the instruction to leave the field empty, the statement that the Adjust module is not breaking, and the absence of any date.
• Make Help Center release notes for 2026 - read 12 September 2026. The three notes tagged "Breaking change" in 2026 and the deadlines in the titles of the other two.
• New compare and swap syntax for the inventorySetQuantities mutation - Shopify developer changelog, posted 12 December 2025, effective 2026-04, flagged "Breaking API Change" and "Action required", read 12 September 2026. The removal of the old fields and the runtime rule that an omitted changeFromQuantity is an error.
• Compare and swap redesign for inventorySetQuantities - Shopify developer changelog, posted 12 December 2025, effective 2026-01, read 12 September 2026. The deprecation of compareQuantity and ignoreCompareQuantity, the fallback to them when the new field is absent on 2026-01, and the plan to remove them in 2026-04.
• Making the changeFromQuantity field required - Shopify developer changelog, posted 12 December 2025, effective 2026-04, read 12 September 2026. The same omit-and-fail rule applied to inventoryAdjustQuantities, the mutation behind Make's Adjust module.
• InventoryQuantityInput - Shopify GraphQL Admin API reference, version 2026-04, read 12 September 2026, together with the same page for 2025-10, 2026-01 and 2026-07. The three states of the field, the "This field is mandatory" sentence, and the presence of the old fields on 2025-10 and 2026-01 and their absence from 2026-04 onwards.
• inventorySetQuantities - Shopify GraphQL Admin API reference, version 2026-04, read 12 September 2026. The description and examples that still use the removed fields.
• Manage inventory quantities and states - Shopify developer documentation, read 12 September 2026. The six-step red shoes example, the CHANGE_FROM_QUANTITY_STALE behaviour, and the single documented case for opting out.
• Shopify API versioning - Shopify developer documentation, read 12 September 2026. The version table with 2026-07 as latest stable, 2026-10 as release candidate until 1 October 2026, and the 16 October 2026 and 16 January 2027 closing dates for 2025-10 and 2026-01.
• changeFromQuantity giving weird error - Shopify developer community, 26 March 2026, read 12 September 2026. The live CHANGE_FROM_QUANTITY_STALE message on inventoryMoveQuantities and the staff explanation of never-set versus zero for the reserved quantity. Whether the same applies to available on first stocking is not covered by the thread or the documentation.
• Reduced functionailty in new v3 modules - Make community, July 2025, read 12 September 2026. The user's account of the email and its notice period for the previous Shopify app transition.
• community.make.com - searched 12 September 2026 for the module name, both old parameter names and the new one, with results ordered by date. No topic about the module or the change since 11 September; the exact phrase "Ignore compare quantity" returned no results at all.
• n8n source, GenericFunctions.ts and Shopify.node.ts - read 12 September 2026 from the raw files on master. The admin/api/2024-07/ base URL on line 40, unchanged since the commit of 29 July 2024, and the resource list of Order and Product.
• Shopify integrations on Zapier - read 12 September 2026 from the page's embedded data. The "Update Inventory Quantity (with line item support)." action, its "Adjust or Set quantity?" field, and the absence of any compare field. The Shopify articles returned by a search of Zapier's help centre were read through its API on the same day; none names an API version.
• Make pricing - read 12 September 2026. Execution log storage of 7, 30, 30, 30 and 60 days for the Free, Core, Pro, Teams and Enterprise plans.