Intermittent 422 error when adding newly created variant to cart via /cart/add.js

Products and Orders APIs
,
1

Hi everyone,

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

  1. Backend creates a new product + variant (used for add-ons / custom products).

  2. Backend sends the newly created variant_id to the frontend.

  3. Frontend calls:

    POST /cart/add.js

  4. 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.js sometimes 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

  1. Is this a known limitation of adding newly created variants to cart via Ajax?

  2. 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.

Thanks in advance!

2

Hi @LIVEARf,

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?

3

Thanks for the context.

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.

4

Thanks for sharing your use case with us :slight_smile:

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.

1 Like
5

Alright, I was able to confirm internally that at the moment the solution is to add fixed delays and retries.