Hi!
This is happening for one of my merchants. When she updates her catalog or location, 2 notifications are sent to the respective webhook. Instead of just 1. The event_ids are different so I don’t think I can use idempotency.
Why could this be? Thanks!
Could the seller have two applications sending webhook events? That’s the only other time I’ve seen events being sent twice. Also what’s your application Id? 
Hey Bryan! 
When you mean 2 applications, do you mean that there was some kind of bug that caused her account to register for my application twice? Or 2 different applications? If the 2nd application isn’t mine I don’t see why the design decision would be to send me the other app’s notification to my webhook’s URL.
My application ID is: sq0idp-n7Co30IXghyF_BPiBvCnBA
The merchant’s ID is: ML9GMW5M8B5Z8
Thank you for always helping!
Looking at the logs I’m seeing that we are resending the webhook because of a failed delivery. I’m seeing up to 9 retries for some events. Is your application responding with a 2xx within 10 seconds?
I had some non-2xx’s before. I fixed that issue and I was still seeing the problem, but now it seems to be only sending 1 notification! I will monitor it and if it comes up again I’ll send the time of the notifications. Thank you!
@Bryan-Square Ok, yes it is still doing it. Check out the catalog update webhook notification for the time at 2022-02-09T19:22:58.007191+00:00 AND there was a 2nd one at 2022-02-09T19:22:58.463058+00:00 . Instead of just 1. Both were the response to the the same catalog tax update I did to the merchant.
(These times are from my server logs so they will be both a bit later than your Square logs I’d think)
Let me know what you think is happening! Thanks.
What are the EventIDs?
I was not logging those before.
I just added code to log them and did the test again, so here is another example of it happening:
First: ff61e097-8a79-4c57-ad95-ce2a1a9fe41c
Then a second! : 90b61858-c0c7-48d8-badc-042b1644821f
Let me know if you see why this might be. Thanks
Hi @Bryan-Square! Just want to follow up. But take your time.
Let me know if you need another example
Thanks for the willingness to provide another example. Were looking into this and I’ll be sure to reach out with any updates.
Thanks! Yeah it’s still happening as of a couple of hours ago so if you need more examples let me know.
Hi Bryan
This is Ashish with HomeTechGeeks. We are seeing the same behavior in our applications. Is there a way to disable retry? We are processing the notifications in a serverless lambda hence cannot guarantee the time it takes to respond to the notifications.
Currently, there isn’t the ability to disable retries. We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team.
For anyone in a similar positon. We updated our logic to push the message to SQS FIFO queue and return 200 immediately to process the message from the SQS queue. We also have deduplication enabled hence if the message is received twice, the SQS queue ignores it.
