Topics covering webhook creation & management, event handling, Pub/Sub, and Eventbridge, in Shopify apps.
Hello,
I don't understand what is happening with my app. It seems like randomly at times, Shopify will send 1000's of requests to my webhook endpoint.
I can assure that the endpoint is returning a 200 status code, so I don't believe that is the cause of this issue.
Are there any known issues with webhooks (or more specifically, the carts/update or carts/create webhook) that cause an infinite loop of requests to app endpoints?
EDIT: Here's some more information:
Every request being made to the 'carts/update' webhook contain a separate ID, so even if 1000 requests are being made for the same store, each cart that's being passed through the body is unique.
Also, all of the shopping carts are created just milliseconds before the 'carts/update' webhook are being called, example:
updated_at: '2019-11-01T15:16:21.119Z', created_at: '2019-11-01T15:16:18.340Z'
There are no items inside of the line_items for any of the requests. Also this issue is not isolated to a single store, there are multiple stores that are exhibiting this behavior.
The request barrage seems to always take place after a valid cart update, however it doesn't occur every time for every store.
Otherwise, I'm not entirely sure what additional information to provide. I really can't tell what is causing this issue. My app is 100% of the time returning a 200 response code, I don't know why I'm being spammed with webhook calls.
What if a Bot farm gets into a shop. A Bot farm can flood carts. Even though Shopify has Bot killers, some get through. Since you are listening to an endpoint that could be affected by that, it is a possibility is it not?
Hmm, I see. Interesting idea. So it seems likely that this would be a bot instead of just some glitch / misconfiguration on my app?
I think it is a very teeny tiny possibility that you as a consumer of webhooks could somehow configure your webhook to be generating thousands of webhooks through misconfiguration. You're not the publisher, you're the subscriber. That being said, if your customer at Shopify got hammered with thousands of carts at the same time, Shopify would be obliged to send you thousands of those carts at some point.
Gotcha. Would you happen to know of any strategies for preventing this activity without breaking the webhook functionality?
Hey @Conner_Pope,
As Bill mentioned, it's possible that carts are being created at a high volume on the client's shop, in which case the webhooks are to be expected. Another possibility is that your app isn't responding to the webhook within 5 seconds, in which case Shopify will re-attempt delivery of that webhook. It could be a little bit of both as well, a higher volume of webhooks could cause your app to take longer to process the webhooks, and if the response time exceeds 5 seconds Shopify will start retrying. In either case, there's a few things you can consider:
- Verify that your app is responding to webhooks right away, and defer any processing of webhook data until after the response is sent.
- Depending on what information you're interested about in the webhook payload, you can filter incoming webhooks (after responding) and discard any that don't meet your conditions. For example, if you're interested in line items you can check for the presence of any line_items in the cart, and only process the webhook if line_items exist.
If both these things are in place, you can send along the webhook_id and approximate timeframe for any webhook subscription where you've observed the issue, and we can investigate further.
JB | Solutions Engineer @ Shopify
- Was your question answered? Mark it as an Accepted Solution
- To learn more visit Shopify.dev or the Shopify Web Design and Development Blog
@_JB I am experiencing the same right now with the orders/updated webhook. It appears to only be affecting a single order:
3 sample webhook ids with nothing in the payload changed except the updated_at timestamp
Hit my server approximately 2022-09-14 16:25
e3f0d3bd-c2f1-4363-a13e-c1c1bd80e14c
b186c3a2-8a51-4999-bcae-75c180c4503a
a0f09cc9-afb0-4920-b7a1-37e881667fe1