# Single webhook event fired 2 times in the span of a few milliseconds **URL:** \ **Category:** Questions\ **Tags:** webhooks-api\ **Created:** [October 27, 2023, 12:33am UTC](https://developer.squareup.com/forums/t/single-webhook-event-fired-2-times-in-the-span-of-a-few-milliseconds/11166 "2023-10-27T00:33:29Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![mtlberri](https://avatars.discourse-cdn.com/v4/letter/m/e8c25b/32.png) [@mtlberri](https://developer.squareup.com/forums/u/mtlberri)\ **Post date:** [October 27, 2023, 12:33am UTC](https://developer.squareup.com/forums/t/single-webhook-event-fired-2-times-in-the-span-of-a-few-milliseconds/11166/1 "2023-10-27T00:33:29Z")
Hi, It happens quite frequently that my app receives 1 single webhook event 2 times in a row in the span of a few milliseconds. I know about idempotency, and I also know that square will try fire again the webhook after a reasonable amount of time if it does not get a 200 back, but here it is different: I receive the initial event 2 times in a row in the span of a few **milliseconds**. My app id is sq0idp-P0lN2wfKfFDEvXXupFMcNg Example: 2023-10-26 10:58:20.903: af56340c-5e29-5a37-a190-e90f5d61a9dc booking.created 2023-10-26 10:58:20.911: af56340c-5e29-5a37-a190-e90f5d61a9dc booking.created ---
**Author:** ![Bryan-Square](https://sea1.discourse-cdn.com/square/forums/user_avatar/developer.squareup.com/bryan-square/32/38_2.png) [@Bryan-Square](https://developer.squareup.com/forums/u/Bryan-Square)\ **Post date:** [October 27, 2023, 4:02pm UTC](https://developer.squareup.com/forums/t/single-webhook-event-fired-2-times-in-the-span-of-a-few-milliseconds/11166/2 "2023-10-27T16:02:35Z")
This is expected since webhooks can be sent more than once. You can bypass the processing of repeated notifications using the idempotency value included as the `event_id` field in the body of each event notification. 🙂 ---
**Author:** ![user4233](https://avatars.discourse-cdn.com/v4/letter/u/48db29/32.png) [@user4233](https://developer.squareup.com/forums/u/user4233)\ **Post date:** [December 1, 2023, 2:15am UTC](https://developer.squareup.com/forums/t/single-webhook-event-fired-2-times-in-the-span-of-a-few-milliseconds/11166/3 "2023-12-01T02:15:47Z")
@Bryan-Square, I’m sorry but I have to add a comment here because it’s the same issue we are having. It makes no sense that Square webhooks notifications are sent at the same time for the same event because the 3rd party system has no time to log the notification and even less time to pull additional payloads with only milliseconds between. Without giving time to process a notification it’s impossible to have any comparison data to define if any other is a duplicate. And in addition, when sending different version notifications also at the same time makes no sense because when pulling payloads you will get always the latest version and never know what the older version had and got changed. So, this Square particular behavior is completely none sense. ---
**Author:** ![MichaelHoltonPrice](https://avatars.discourse-cdn.com/v4/letter/m/4491bb/32.png) [@MichaelHoltonPrice](https://developer.squareup.com/forums/u/MichaelHoltonPrice)\ **Post date:** [April 2, 2024, 6:05pm UTC](https://developer.squareup.com/forums/t/single-webhook-event-fired-2-times-in-the-span-of-a-few-milliseconds/11166/4 "2024-04-02T18:05:20Z")
I also want to chime in here. One problem may that the event\_id is not a true idempotency key. Here are two webhook events that I am almost certain we successfully received (responded with 200): { “merchant\_id”: “MLY5F08WVFJBG”, “type”: “order.updated”, “event\_id”: “b349a949-ae52-3920-832d-610b1ae2a75d”, “created\_at”: “2024-04-02T17:41:37Z”, “data”: { “type”: “order\_updated”, “id”: “HGsO2YYAvEfcDcTRnkl7QwXFN17YY”, “object”: { “order\_updated”: { “created\_at”: “2024-04-02T17:41:05.203Z”, “location\_id”: “LPWMHRSSSJBT6”, “order\_id”: “HGsO2YYAvEfcDcTRnkl7QwXFN17YY”, “state”: “OPEN”, “updated\_at”: “2024-04-02T17:41:36.823Z”, “version”: 6 } } } } { “merchant\_id”: “MLY5F08WVFJBG”, “type”: “order.updated”, “event\_id”: “b349a949-ae52-3920-832d-610b1ae2a75d”, “created\_at”: “2024-04-02T17:41:37Z”, “data”: { “type”: “order\_updated”, “id”: “HGsO2YYAvEfcDcTRnkl7QwXFN17YY”, “object”: { “order\_updated”: { “created\_at”: “2024-04-02T17:41:05.203Z”, “location\_id”: “LPWMHRSSSJBT6”, “order\_id”: “HGsO2YYAvEfcDcTRnkl7QwXFN17YY”, “state”: “OPEN”, “updated\_at”: “2024-04-02T17:41:37.013Z”, “version”: 7 } } } } How can event\_id be treated as an idempotency key when your internal order state marker, version, has changed? All the best, Mike Price, PhD ---
**Author:** ![BrianC](https://sea1.discourse-cdn.com/square/forums/user_avatar/developer.squareup.com/brianc/32/112_2.png) [@BrianC](https://developer.squareup.com/forums/u/BrianC)\ **Post date:** [May 7, 2024, 4:53am UTC](https://developer.squareup.com/forums/t/single-webhook-event-fired-2-times-in-the-span-of-a-few-milliseconds/11166/5 "2024-05-07T04:53:44Z")
Mike, You’re right in that event\_id isn’t truly an idempotency key; it’s just a unique id for that transaction. If you get a second webhook event with that event\_id you simply check for a later “version” value than the previous webhook hit, and do an immediate exit without further processing if the “version” is less than or equal to that of the last event with that event\_id. This does mean that you have to save the version each time you process a webhook hit. It also means that if you have enough data in the webhook hit you can go ahead and initiate further processing. The later version event webhook posts just update things like the processing fees etc. Square: it would probably be useful if there was some way to tell whether a particular web event post was “final”. If there’s no way to know that, the webhook processing will need to take into account that no event webhook hit can be considered final. The lack of a sense of “final” makes webhook processing harder than it should be. I can also understand that this might not be possible for internal reasons, just raising it because it would help. In practice, the “version” value will go to about 4, with hits for about 4 of those “version” events (ie: 3 versions don’t appear to generate webhook hits).