Depending on the configuration of the store it’s possible some of the calculations involved with a modification of the checkout are happening async. On the Checkout object there’s a ready field that can be used to determine if the checkout is in a state to be completed. In the event the ready field does not returning as true in the response from the mutations mentioned, you can query the checkout object at an interval of your choosing to determine when all calculations have been completed.
I hope this helps, if you have any other questions please don’t hesitate to reach out.
We do support web hooks for checkout actions like create, update and delete.
In my own testing I haven’t seen these calculations take longer than a couple of seconds. That being said, server load, and factors like using external tax engines or external shipping rates pulled through using Carrier service API can impact these times.
The intent is too quickly provide a response to your initial request, while also communicating that calculations are not complete. In particular mutations affecting the checkout total like selecting a shipping line or adding a discounts need to re-calculate things like taxes so we prefer to handle those operations async and provide a means for your to know when they are complete.
I do have a recorded issue on this point as I can see the opinion that the async approach isn’t ideal for everyone so this could possibly change in the future, I just don’t have a timeline on if or when that might happen.
I am receiving a null value for shippingLine even though the checkout object is ready and I have made a request to checkoutShippingLineUpdate with a 200 response.
I apologize for the lateness in my reply. When receiving the response to the shippingLineUpdate mutation if you were to make a subsequent query of the checkout does the shipping line in that response show up as populated?
For example to query the checkout,
query getCheckout ($checkoutId:ID!){
node(id: $checkoutId) {
... on Checkout {
id
ready
webUrl
email
lineItems(first:10){
edges{
node{
id
quantity
}
}
}
shippingAddress{
address1
city
zip
}
shippingLine{
handle
priceV2{
amount
}
}
}
}
}
I look forward to hearing back from you, and on the subsequent reply if you could provide the checkout id used in your more recent test I’ll have a look at our logs with that.
Thanks for providing that checkout id. Did the shipping line show in the response to that subsequent checkout query after you set the shipping line with the checkoutShippingLineUpdate mutation?
In our logs I’m not seeing a subsequent query for the checkout after the checkoutShippingLineUpdate. For the checkout id provided I am seeing the query happening after an address update which does reset the shipping line to null.
If you take the checkout id provided in your earlier reply and just try that query with Insomnia or Postman do you see same where the shipping line is still null?
I was using a separate request to get the updated checkout information rather than using the shipping line mutation to get the updated checkout object. When I return all the info from the mutation, I seem to be getting the up to date object!