We’ve identified the root cause as an inventory syncing issue and shipped a fix. 422 errors should now be rare but not completely non-existent (data population still takes time).
Thanks all for reporting this issue!
If you’re still encountering issues, please share recent request IDs we can investigate, as @ahmedrizwan239 has done.
Yes Still facing issue Request ID: 01300b04-c35f-406e-bccf-8eef4d04f19e-1775009243
Thanks for your patience while I looked into this.
The 422 in these cases is expected behavior. There’s a propagation window
between an Admin API write and when the cart service recognizes the new
variant as eligible. Hitting /cart/add.js during that window returns a 422.
Immediate cart availability after variant creation isn’t guaranteed.
There’s no endpoint or webhook to signal when a variant is “cart-ready,” so
retry logic is the best approach if you’re still encountering issues.
We are having the same issue. Request ID: dbbadf6b-e705-4ff4-b539-9bb2d0f5d7f2-1776308501
{“status”:422,“message”:“The product ‘Traditional Lentil Stew’ is already sold out.”,“description”:“The product ‘Traditional Lentil Stew’ is already sold out.”}
The product is in stock, assigned to a shippable location.
Update:
We’ve investigated the additional request IDs reported here, and can confirm these cases experienced expected behavior. The increased complexity of products over time has led to an increase in propagation time.
If you’re still experiencing this issue after the optimizations we’ve recently made, retries with exponential backoff remain the best available approach going forward.
Also dealing with this issue.
I made an observation that may be useful if you’re dealing with this.
When you create the variant with stock tracking enabled (and also link it to a location and give it stock, I just give it 9999) - the propagation delay is gone, no more 422’s.
Could be a workaround depending on your situation. Disabling stock tracking seems to be triggering this delay.
In regards to the propagation time issue, I wanted to share this additional tip I found helpful for variant-readiness failures:
With newly created variants, admin / products.json can look fine while the storefront cart path still rejects the exact variant ID for a short propagation window (or forever if the ID/quantity/selling-plan path is wrong).
Quick isolate:
If you want a single deterministic public check of “does this variant+qty enter cart and reach checkout right now,” we published a small Apify Actor that does exactly that: Shopify Variant Cartability Checker · Apify
Note: Minor self-promotion, but hopefully helpful nonetheless!
This issue is ongoing, and in fact I would say it has gotten worse. About a year and a half ago I could create a product via a backend middleware, pass the variant id to my js code and immediately add it to the cart, round trip took mostly under 1 second, using the REST API
Now Im using graphql to synchronously create a product and exponential back off loop to try and add the product to the cart using js and it takes more than 30 seconds or more to add the same product. Its hard to explain to the merchants how things have gotten worse and not better when their subscription prices have gone up.
This is a huge degradation in performance guys.
Product was created in shopify response header date shows : Wed, 21 Oct 2026 06:47:48 GMT
first add try of existing variant:
x-request-id: d50ff550-79be-4fde-a91d-2ae080039831-1792565269
date: Wed, 21 Oct 2026 06:47:49 GMT
Second Attempt 10 seconds later:
x-request-id: 5e02dc9a-dbf5-4755-ac90-6a6e8d32d876-1792565279
Wed, 21 Oct 2026 06:47:59 GMT
Third attempt some 20 seconds later :
x-request-id: 04bb63ad-d4f4-4fdf-bd7b-423cc25040b3-1792565300
Wed, 21 Oct 2026 06:48:20 GMT
Fourth:
which was successful:
Wed, 21 Oct 2026 06:48:59 GMT
Even creating a product now takes way longer than it used to take, I would have expected improvements in speed over time not degradations.
ps: I tried to add stock as suggested and it doesnt change anything
Regards,
Gary