Understanding adding cart attributes to webhook

[JoshS]

I posted this question elsewhere, but think old post comments may not get noticed.

I am thinking about trying to use this method as a round-about way to get a `customer.id` in my webhook payloads for `cart/update` and maybe `cart/create` (if a customer exists at that time). I have followed the instructions here as I think I understand them. For example, in our cart template (`cart.liquid`):

{% if customer %}
        <div class="cart-attribute__field">
          <input type="hidden" name="attributes[customer]" value="{{customer.id}}">
        </div>
{% endif %}

Then, in a private app, I'm registering a webhook like this:

const registerCartUpdateBody = {
    webhook: {
      topic: 'carts/update',
      address: `${listeningURL}/shopify/cart/update`,
      format: 'json',
      fields: ['note_attributes']
    }
  };
  const registerCartUpdateOptions = {
    ...options,
    ...{
      method: 'POST',
      body: JSON.stringify(registerCartUpdateBody)
    }
  };

I can see that `note_attributes` is a registered field when I get back the webhook registration object (JSON), but I don't get back any value in my payloads from the cart update event. Is there something I'm not understanding or doing incorrectly? Thanks.

[KarlOffenberger]

Hi Josh,

The approach you link to will not work for cart/create and cart/update webhooks. The attributes are only passed on once the order is created upon checkout.

Instead, you'd need to rely on your own Ajax calls from the cart to your own API if you wish to correlate authenticated customers and their cart.

Best wishes!

[JoshS]

Thank you, Karl. Too bad to hear, because I thought I'd found the secret to passing non-standard values into a webhook payload. We want to associate all cart actions with logged-in customers, and of course the cart object is disassociated from a customer, by default (for obvious reasons).

We have a custom app with an exposed API that we can use to do this from the client, and it will be simple to do on page load events, but now we'll have to write more fragile front-end code to capture AJAX-only cart events and send those to our application, rather than being able to depend on webhooks to capture all cart actions and know the customer at that time, if one is logged in.

This would be a good feature to have available, and I've looked over many other posts that seem to be asking for the same thing (basically, the ability to set custom webhook values or meta-values).

Regards,

Josh

[JoshS]

On that note, if there's a non-fragile (i.e., programmatic, without reference to specific markup) way to capture cart AJAX events, and we've missed that, please point me in the right direction. Thanks

[KarlOffenberger · Accepted solution]

I haven't done it and what I haven't done or at least POC'd with some tests, I cannot confirm, but I'd argue it's worthwhile noting that there are 3 or so ways to manipulate the cart - good old form, Ajax, fetch. Form submits can be easily intercepted and this being Shopify, the /cart post action is a stable UI independent contract if you will. Ajax will be some form of XHR requests which IIRC can be intercepted (XMLHttpRequest.prototype.open and what not) so you'd be free to reliably intercept the Shopify Ajax API requests regardless of jQuery and UI implementation details. Fetch same story but I believe you'd be hard pressed to find that many stores using Storefront API directly... besides, if they are and have built up a fancy React | Vue PWA or what not, they don't have a classical Shopify cart anyway (and Storefront API doesn't have that concept either) 😉

So while I cannot offer you a definitive answer, I do believe there are fairly robust contracts on offer besides webhooks which themselves are anything but robust.

[JoshS]

Thank you. Intercepting the AJAX requests seems like maybe the way to go. Form submits shouldn't be an issue, because we're architecting things such that we will just default to grabbing the customer and cart on page load (reload) and then communicating with our custom application as needed. The crucial flow we need to capture is when someone logs in (without a cart already established), adds some items to a new cart from a product page, and never triggers a page reload during that session. As soon as this happens, we want to store the association between the customer and the cart (basically, as soon as a logged-in customer "creates" a cart). Obviously, if every webhook event could pass a customer id, we wouldn't even need to do this client-side.

[KarlOffenberger]

I'll give you a shout once I get around to the cart and GA integration and hopefully you'll save me from further hair loss 😆

[JoshS]

Not sure about that, and I myself have barely any hair to lose 😆

[edwardupton]

Did you ever get this to work? We also want to build an app to get `note_attributes` when the cart is updated

[Josh68]

Hi, @edwardupton

Very late reply here. We managed to get what we needed to make our app work as intended, but it didn't involve any custom attributes or getting them from within a webhook. In the end, I think I decided webhooks were of somewhat limited utility for our purposes, given that we wanted to update a database as close to real-time as possible. So this whole path I pursued might have been a bad one for our purposes, anyway. Hope you've figured out a solution for your app.

Regards,

Josh

[edwardupton]

Thanks for following up @Josh68 . Our workaround was to add cart object in the liquid template for the page, and send it to our server from there.