GraphQL API: inventoryMoveQuantities / inventoryAdjustQuantities returning “The quantities couldn't be moved/adjusted. Try again.”

Technical Q&A

Topic summary

A developer is encountering intermittent errors when using Shopify’s Admin GraphQL API mutations inventoryMoveQuantities and inventoryAdjustQuantities for inventory syncing.

Error Messages:

  • “The quantities couldn’t be moved. Try again.”
  • “The quantities couldn’t be adjusted. Try again.”

Key Details:

  • No specific userErrors are returned with the failures
  • All required IDs (inventoryItemId, locationIds) are confirmed valid and exist
  • Errors occur sporadically, not consistently

Suspected Causes:

  • Rate limiting or API concurrency restrictions
  • Internal locking/transaction conflicts from simultaneous API calls
  • Temporary Shopify-side infrastructure issues

The developer is seeking clarification from others who’ve experienced similar issues or from Shopify staff regarding the root cause of this behavior. The discussion remains open with no resolution yet.

Summarized with AI on November 2. AI used: claude-sonnet-4-5-20250929.
1

We are using the Shopify Admin GraphQL API to sync inventory quantities.

Sometimes when we call the inventoryMoveQuantities or inventoryAdjustQuantities mutation, we get the following error messages:

The quantities couldn't be moved. Try again.

or

The quantities couldn't be adjusted. Try again.

No specific userErrors are returned.
All IDs (inventoryItemId, from.locationId, to.locationId) are valid and exist in our store.

In particular, I’d like to know whether any of the following might be related:

  • Rate limit or concurrency issues
  • Internal locking or transaction conflicts when multiple API calls run simultaneously
  • Temporary errors on Shopify’s side

If anyone has encountered the same issue or if someone from the Shopify team can clarify this behavior, I would greatly appreciate it.

2

Hi @t-kuzuma

Yes, this is a common issue. That generic “couldn’t be moved” error, with no userErrors, is almost always a concurrency or rate-limit problem.

It means you’re sending too many inventory updates at once, and Shopify’s system is temporarily “locking” an inventory item to update it. When your next API call tries to update that same item while it’s still locked, the call fails.

The solution is to retry the request with exponential backoff. When you get this error, don’t treat it as a final failure. Instead, wait for a short, random period (like 1 second) and try the exact same call again. If it fails again, wait longer (e.g., 2 seconds), and so on, for 3-5 retries. This gives the lock time to clear and your subsequent attempt will succeed.

Hope this helps!

1 Like
3

Hi @PieLab

Thanks for the helpful answer!
I have one more question related to this issue.

To detect this error, I’m currently checking the error message (for example, "The quantities couldn't be moved. Try again.").
However, I was wondering if it would be better to rely on an error code instead of the message — in general, using a code seems more reliable.

But in this case, the code field is nil even though I expected something like MOVE_QUANTITIES_FAILED.
Here’s what I’m seeing in the GraphQL response:

(byebug) data.dig(route_element_name, "user_errors")
[{"field"=>nil, "message"=>"The quantities couldn't be moved. Try again.", "code"=>nil}]

(Reference: InventoryMoveQuantitiesUserErrorCode)

So I’d like to confirm:

  1. Is it expected behavior that code is nil for this type of error?

  2. Is checking the message text the only practical way to detect this case?

  3. Are there any other reliable ways to distinguish this error?

Thanks again for your time and clarification!

4

Error messages and code-identifiers can change without notice.
Relying on error checking is still basically just attempting to red-line a system.
Before remediation* steps check rate limiting first, if under a threshold then do any static checks against text .
*which is not the same as logging an error or sending a notification

For actual depth on response-content use the actual developer forums it has a waaaaay higher chance of shopify staff commenting on such behavior.

5

@PaulNewton

Thanks a lot for the clarification!
I didn’t realize that even error codes can be unreliable or change without notice — that was new to me and very helpful to know.

Thank you as well for pointing me to the developer forums; I’ll check there for more details. Really appreciate your help!

1 Like
6

This is true on most platforms, unless the docs/api have like ENUMs for such things thiers not really a contract just a tradition.

On shopify about the only indicator of a “reliable” error message string would be if you see it hard coded in one of shopifys demo codes/repo/apps; but still treat as heuristic .
For example in themes you may see strings for checking errors from cart/inventory issues in the frontend ajax api response. But it’s not really documented as an unchangeable thing though the changelogs might maybe note when such things are modified /le sigh

No need to reply.