Hi,
We have highly customizable products around 10 options and each option having multiple options and some options depends on other options value. It’s worth to be mentioned that, based on options, the prices are also updated. We are selling wood hood products. As a result we cannot pre-populate all the variants. So, we create a variant when user click on “Add to Cart” and then use “cart/add.js” endpoint to add the product to cart.
But this fails instantly and if we retry it works then, so, we created a script to keep retrying unless it’s added to cart but this is impacting AOV (Average Order Value) and time is sometime around 5seconds.
How can we reduce time for “cart/add.js” after dynamic variant creation. Or what should be our workaround for this.
Hi @illusionist3886! Your read on the timing is right. There’s a short window after a variant is created where it’s already readable through the Admin API but the storefront cart still sees it as out of stock, so the first cart/add.js comes back as unavailable and a retry a few seconds later succeeds. The variant rows that back the cart’s availability check are populated by a background job, and that’s what takes the few seconds to complete.
For a highly configurable, made to order product like this, the cleanest fix is usually to skip per click variant creation entirely and use Admin API draftOrderCreate with a custom line item instead. You pass a title and a price directly (no variantId), add the selected options as line item custom attributes, and redirect the buyer to the returned invoiceUrl.
If you’d rather keep creating real variants, two things can help. First, set a positive inventory quantity at the location when you create the variant (via productVariantsBulkCreate with inventoryQuantities, plus inventoryPolicy: CONTINUE if it’s effectively unlimited), which should make the variant purchasable immediately rather than starting at zero. Second, before calling cart/add.js, poll the product (the Storefront API, or /products/{handle}.js) until the new variant shows as available, then add it, behind a brief loading state. A gentle backoff of a couple of seconds with two or three attempts is plenty.
To narrow it down on your end, could you share which mutation and API version you’re using to create the variant, whether you set any inventory on it at creation, the exact status code and body from the failing cart/add.js, and an x-request-id from one of the failing calls? That’ll let me confirm what your variants look like at the moment of the add and whether the inventory route would help clear it up.