I’m facing an intermittent issue when creating a product variant dynamically via the Admin API and immediately adding it to the cart using /cart/add.js.
What I’m doing
Backend creates a new product + variant (used for add-ons / custom products).
Backend sends the newly created variant_id to the frontend.
Frontend calls:
POST /cart/add.js
Sometimes it works, but very often it fails with 422 Unprocessable Entity.
Important observations
GET /variants/{variant_id}.json returns 200 OK
The variant clearly exists and is readable
Product is published to Online Store
Variant has price, shipping enabled, and no inventory restrictions
Adding a delay before /cart/add.jssometimes fixes it
but the delay is inconsistent (1s, 4s, 6s, etc.)
Retrying aggressively leads to 429 / Cloudflare challenge responses
What makes this confusing
variant.json being accessible suggests the variant exists
But /cart/add.js still rejects it with 422
This looks like a propagation / cart-readiness delay
There doesn’t seem to be a reliable signal to know when a variant becomes “cart eligible”
What I’ve already tried
Fixed delays before adding to cart
Retry logic with backoff
Checking variant availability via /variants/{id}.json
Ensuring product is published to Online Store
Ensuring variant is not draft and has valid price
None of these are reliable in production.
Questions
Is this a known limitation of adding newly created variants to cart via Ajax?
Is there a supported way to detect when a variant becomes cart-ready?
Use case
Custom products / add-ons
Variant must be created dynamically
Immediate checkout experience expected
Expected behavior
If a variant:
exists,
is published to Online Store,
and is readable via public endpoints,
it should either:
be addable to cart, or
provide a deterministic way to know when it becomes addable.
Any guidance from Shopify staff or developers who’ve handled this would be really appreciated.
There can be a slight propagation / cart-readiness delay for newly created variants/products. I’ve seen this happen with a few shops that like to create an entire new product or variant on the fly for customers with custom requirements.
They all seem to use the same workaround approaches you have already tried though. I’ll investigate on our end to see if there is a more reliable approach.
In the meantime, I’d like to learn about why you need to create new variants for add-ons/custom products. Is there a platform limitation that you are working around? Are line item properties insufficient?
In our case, buyers upload an image that needs to be visually reflected on the checkout page so they can confirm they’re purchasing the correct item.
Since the checkout UI only displays the variant image (and does not render line item properties or uploaded assets visually), we currently rely on creating a new product/variant and assigning the buyer’s uploaded image as the variant image. This ensures the correct image is shown to that specific buyer during checkout and order review.
Line item properties work well for metadata, but they don’t allow us to visually represent the uploaded image in checkout, which is important for buyer confirmation and reducing order errors.
That’s the primary reason we’re creating variants dynamically rather than using a single pre-existing variant.
Plus merchants have the option of utilizing the update operation of the Cart Transform Function API to change line item images in the cart and at checkout, but image update doesn’t persist to the Order Status page or Customer Account pages.
I’ll keep looking into whether there’s a better way to address the delay, but so far it looks like the current approach with fixed delays and retry logic may be the best option for now.
What is the solution for this issue? Sometimes it keeps returning a 422 error. Some of our clients are frustrated because of this. Please look into it and do the needful
422 responses are typically due to malformed requests.
Can you share an example payload of a request when this issue occurs?
You might find it helpful to compare it against a request that returns a 200 status to understand what needs to be corrected.
It looks like the reason you’re seeing a 422 response is because the variant is sold out. Does the variant have sufficient stock? If it does, please reach out directly to support so we can investigate potential issues with inventory.
However, using fixed delays with retry logic is leading to 429/Cloudflare rate limit responses in production, and adding delays in the add-to-cart flow is negatively impacting conversion rates.
Since the variant returns 200 OK via /variants/{id}.json, but intermittently fails on /cart/add.js, this appears to be a cross-service propagation delay.
Is there an officially recommended way to detect when a newly created variant is fully available to the cart service? Relying on arbitrary delays is not reliable for production use.
At the moment we don’t have a way to detect when a newly created variant is fully available to the cart service. The only way to confirm is a successful add to cart request.
To help prevent 429 errors, you can use a loading screen before the initial request. To improve the customer experience during this delay you can display creative status messages.
For example, for a customized shirt, you could show a sequence like:
We have exactly the same flow. What we do is duplicate a product with a custom/updated price so customers can add it to their cart and checkout directly without any issues.
This has been working for 4-5 months but recently, it suddenly stopped working and the flow is crashing because of this.
Is there a solution for this or a timeline for when we can expect a fix? Also, how can we detect if a product is ready to be added to the cart? @Paige-Shopify
I’ve also found this issue occuring on some stores. We’ve been creating variants on the fly for almost six years now, and this is a fairly big change, if it is intended.
We wait until the variant is propagated to the product in the online store, then add it to the cart, but even this is no longer guaranteed to work.
@ahmedrizwan239 and @Bsmubbs thanks for reaching about this and sharing your experience. Can you tell me more about what has changed recently? Are you referring to the 429 responses blocking your retry attempts?
