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.
