Hello,
We noticed a strange case where a specific checkout that was created at 28/08/2025 was only received on our end via checkouts/createwebhook on 06/09/2025 along with all the subsequent checkouts/updateevents.
This relates to checkout id: 45320149631309
Our logs show that, the headers for the checkouts/createwebhook call were:
x-shopify-topic: checkouts/create
x-shopify-triggered-at: 2025-09-06T18:14:57.323327933Z
x-shopify-webhook-id: b4eba137-c78c-424e-954d-c40b2466539e
And in the body of the webhook contained:
created_at: 2025-08-28T07:26:18+00:00
And after this webhook we also received all the subsequent checkouts/updatecalls for the same checkout.
This causes problems for some flows in our systems that rely on the proper timing of webhook receipts.
Let us know if we should provide more data so this can be debugged on your side.
Thanks!
Hey @khaledAtKeaz, thanks for reporting the delayed webhooks here and the impact you have shared. That is quite a delay. Was a single order affected here, or are you still receiving delated webhooks?
The first thing I would check here is the order timeline. Is there anything there to point to either of those dates? This may give some insight in to if any actions on the 6th lead to the webhook firing with earlier created at dates.
Hey @KyleG-Shopify,
We believe it occurred multiple times since we had more than one report of delayed actions, we investigated the case I sent over and what I could confirm is that the customer left some items in their cart on 2025-08-28, we then got no webhooks, and some days later (on 2025-09-06) they updated the cart and made an order, and then we got all the webhooks in the normal order (checkouts/create, and then a couple of checkouts/update events) which of course caused for some wrong calculations on our end since we consider the created_at on the webhook data and not when it was sent.
In the original post, we also provide some specific webhook information (e.g. event IDs and exact dates of receipt)
Let us know if there is anything further we can provide for you to be able to further investigate/debug this..
Best,
Khaled
Thanks for sharing that @khaledAtKeaz!
I’ve run several tests trying to replicate this behavior, and what I found suggests this might actually be expected behavior. When I created a checkout, left it, and returned to complete it later, I received two separate checkouts/create webhooks for the same checkout. The first fired when I initially visited checkout, and a second one fired when I returned to complete it. Both webhooks showed the same created_at timestamp (the original creation time) but different updated_at times, which matches exactly what you’re seeing.
To help troubleshoot this further, can you share more details about your specific webhook subscriptions and the business logic you’re trying to implement? The reason I ask is that throughout all my tests, the cart token remained constant across multiple checkout sessions, so using cart-based tracking might be more reliable for your use case, especially considering the recent deprecation of Checkout APIs in favor of the Cart API.
Hey Khaled, Are you still experiencing this issue, or can I mark this as solved?
Hey @KyleG-Shopify
We haven’t been monitoring it heavily, but we also got no reports from customers recently.
Then I would say let’s mark it as archived or solved for now. Thank!
1 Like
What Kyle described is pretty common with checkout webhooks, when a customer abandons and returns later, Shopify essentially treats it as a new session triggering another create event even though the underlying checkout object already exists.
The tricky part is exactly what you experienced, the created_at stays the same but the webhook arrives much later. If your logic assumes webhooks arrive close to when the event actually happened, things can get messy quick.
One pattern that helps is to always compare the updated_at timestamp against your last known state for that checkout rather than trusting created_at for sequencing.
Kyle’s suggestion about cart token tracking is solid too since it remains consistent across sessions. Shopify’s been pushing toward cart based flows anyway (https://shopify.dev/docs/api/ajax/reference/cart).
For what its worth, if you find yourself constantly working around webhook timing issues, there are sync based approaches that pull data directly rather than waiting for webhooks to arrive. Tools like Stacksync can keep your database in sync with Shopify in real time without relying on event delivery, which sidesteps a lot of these timing headaches. Might be overkill for your case but worth knowing about if this keeps causing problems.