NOTE ON UNIQUENESS: We do not guarantee that you will only get a single notification for an event. Though this should be rare, it is possible that we will send you the same notification multiple times.
So we have a list of eventId that we already treated, and ignore any notification with an eventId that was already treated.
However, after subscribing to contact creation, and multiple propertyChange, when creating a contact, we receive a single batch notification with multiple objects, all of which share the same eventId, and the same occurredAt.
I understand that the contact creation was the single event that triggered all these notifications, but if we can not use the eventId as a marker of "Which notification objet was already treated", which ID should we use to detect duplicates ?
Thanks for your explanation.But my issue is a bit different from what you explained . I subscribed only for property change and not for creation event .Eventhough the webhook sends request to the end point when the event occurs , the request receives at the end point as multiple request .Since the end point is called multiple times (here it is two times) , my program logic is executing multiple time parallally and finally two records are created for a single event occurense.
Thank you for this precision. I updated our duplicate detection hash, so it now combines eventId and subscriptionId. I would suggest you guys add this point to the doc.
I also sent you a private message with an example of notification about the timestamp issue.
I apologize, I misspoke. The combination of eventId and subscriptionId are unique among notifications. I said subscriptionType instead, which was not accurate; there can be distinct subscriptions of the same type, and therefore there can be notifications with identical eventId and subscriptionType. Notifications with identical eventIdandsubscriptionId are duplicate notifications. Notifications with different eventId and/or subscriptionId are not duplicates, but distinct notifications.
Regarding the issue you mentioned with occuredAt; do you have any example webhook logs that I could look at that demonstrate this incorrect ordering? I'd love to dig into that further.
These 3 properties are not enough to generate a unique hash: we also need to add propertyName, I already received notifications with identical eventId, subscriptionType, and occurredAt, but different propertyName (when multiple properties are updated in the same time)
Also: different bug, but the occurredAt dates are wrong: On a contact creation, we receive a notification with a contact.creation and multiple contact.propertyChange. The contact.propertyChange are dated (occurredAt) earlier than the contact.creation so we have to sort them by type first before treating them, we can't just rely on the occurredAt.
The eventId field is the unique ID of the event that triggered the notification, so a single eventId can have multiple different notifications if the subscriptionType is different. For notifications to be the 'same' in the context
of the note on uniqueness above, they must have the same eventId, subscriptionType, and occurredAt fields.
In the scenario you described, the eventId corresponded to a contact being created. This triggered a notification in the contact creation subscription, and for any contact property change subscriptions that were affected. These were all related to the same event, but they were notifications for different subscriptions, and therefore weren't really duplicates.
If you don't care about property change notifications for contact creations, you could ignore any property change notification with the same eventId as a contact creation notification. Otherwise, you should treat these notifications as separate, since they're notifying of different aspects of the same event.
.png "HubSpot Alumni"){kind=icon}
