[Feature request] Ajax API: Get full cart in /add.js request response

Context

In the AJAX API, both the /change.js or /update.js requests respond the the entire cart back as a response, which is super convenient because it’s important for me to get updated data in regards of product prices and cart total.

The problem is that every time I use the /add.js endpoint, I need to generate an additional request to get the cart again, because automatic discounts could have been applied to any other products and I don’t have any way of noticing it.

The only discounts that I can access in this situation are inside the discounts property of the added product, which wouldn’t be enough information to know what the cart total is.

The ideal solution

It would be ideal if we could optionally request the AJAX API to return the entire cart in /add.js requests, maybe via an optional param, header or similar.

I know this is pretty specific, but it’s the only real limitation I’ve run into with the Ajax API, that I haven’t found a workaround for. I’ve found no other way to have a 100% certainty of the cart total.

Hope this request can be considered, thank you!

1 Like

Hey @Pridentt :waving_hand: thanks for flagging this and great call out.

You’re right that there isn’t a native flag to make /cart/add.js return the full cart, but you should be able to use the Section Rendering API to get updated totals in the same response: Section Rendering API.

You could potentially create a small theme section that outputs cart totals (or the full cart) as JSON, then call /cart/add.js with sections=your-section-handle (and optionally sections_url=/cart) so Shopify returns that section alongside the normal add payload.

In the response, you could technically read data.sections['your-section-handle'] to get the totals after automatic discounts, avoiding a second /cart.js request.

Just wondering if this might meet your needs? If not, let me know and I can reach out to our devs to set up a formal feature request for an optional “return cart” flag on add.js and look into any other workarounds (happy to set up the feature request either way too!). Hope to speak soon!

1 Like

Thank you for taking the time to check this @Alan_G.

Regarding the potential solution via Section Rendering API: is it possible to create that specific cart JSON section without modifying the theme code? I’m reading the docs and haven’t found a way, it seems I can only request the existing ones.

I’m asking because I’m working with an theme app extension, so as far as I know, I can’t modify the theme’s sections folder.

Hey @Pridentt, thanks for clarifying that you’re building an app extension. Right now, there isn’t a way to create that section without access to the merchant’s theme code as you mentioned there.

That said, I’ll get in touch with the product team for you to see if they know of any workarounds/to send up that feature request for you. I’ll loop back here once I have more info to share.

2 Likes

Thanks a lot @Alan_G! Really appreciate you taking the time to hear this suggestion :folded_hands:

Hey @Pridentt — thanks again for your patience while I followed up.

There still isn’t a native flag for /cart/add.js to return the full cart, but there is a supported way to get updated totals in the same response without a second /cart.js call.

If you include a sections parameter in your /cart/add.js request, Shopify will re-render those theme sections after the add mutation and return them alongside the normal add payload. You can also include sections_url=/cart to ensure the sections are rendered in the cart context. The JSON response will include a sections object keyed by the section IDs you requested; you can read response.sections['your-section-id'] to get the HTML for updated totals and any other cart changes after automatic discounts are applied. This is the same pattern some of our themes use to update the cart drawer immediately after add-to-cart.

Since you’re building a theme app extension, you can’t create a new JSON-only section, and that part hasn’t changed. However, you can still request existing cart sections that the merchant’s theme already exposes (for example the cart drawer or cart totals section) and parse the returned HTML for the totals or any line-level changes. If the theme doesn’t have a suitable section to target, the extra /cart.js call remains the fallback. Here’s what this looks like in the request though:

Hope this helps/makes sense, let me know if I can clarify anything on my end here as always!

Hey @Alan_G , thank you for following up.

I’m aware that I can use the Sections API to get the updated HTML and get the total value from there, but this raises 2 problems:

  • First, the HTML in the section response will be inconsistent across different themes, making it infeasible to make my parsing work in all themes
  • Second, I used the example of the cart total just to explain a simple use case, but in reality I need all the cart data: updated lines (like ids, keys, attributes), discounts (at cart level and line level), quantities, subtotal. This is because of the needs of my app.

I hope this clarifies the why behind the request. Will the development of this feature be considered still?

Thanks @Pridentt - definitely understand where you’re coming from. I can’t guarantee anything when it comes to exact timing for feature releases, but I can set up a feature request for you for sure so that we can continue considerations for this. I can loop back with some folks internally to see if this is on the roadmap as well, and at the very least log a feature request for you that I’ll share with our product team.

I’ll loop back with you once I have next steps to share. Thanks again for following up - speak soon!

@Alan_G I’d be super grateful if you could create that feature request for the team to consider it and add it to the roadmap.

If I can assist with anything else here, please let me know.

Thanks again!

Hey hey again @Pridentt - just replying to you back to back here! :smiley:

I was able to touch base with our product team for you again on this issue. It’s not currently on our roadmap, but I have logged a feature request for you and our devs do see it potentially useful for sure. Again, can’t guarantee anything in terms of the implementation or timeline, but did just want to loop back with you here to let you know I’ve set up the feature request on my end here on your behalf.

Thanks a lot @Alan_G, appreciate the consideration, I hope they will add it to the roadmap :folded_hands:

Have a good one!

1 Like