Jun 30, 20227:29 AM - edited Jun 30, 20229:56 AM
Member
Receiving more than one webhook for same event on Contact Creation
SOLVE
Our application receives webhooks of contact.propertyChange subscription type when new contact is created in Hubspot.
Even though our system is coded to avoid duplicate on the occasions of multiple notifications for same event, these webhooks cause duplicate entries as webhooks are triggered within negligible time difference.
Kindly rectify this issue as well as guide us with ideas to resolve this problem
Typically we set up a Job Queue to do the work after we've sent a reply to HubSpot. THis alllows us to reply to HubSpot as soon as we can when we receive the information.
We have noted attemptNumber and verified that these duplicate webhooks are not caused by timeout.
I have replicated the one scenario where I encountered this issue. I have observed the following in the trial:
Once I created contact in Hubspot, I received two webhooks with negligible difference i.e. <100ms.
The payload of first webhook contains array of three objects of subscriptionType contact.creation, subscriptionType contact.propertyChange for properties firstName and lastName respectively.
[
{
"eventId": 1980502853,
"subscriptionId": 3106,
"portalId": 22235544,
"appId": 43891,
"occurredAt": 1657014641516,
"subscriptionType": "contact.propertyChange",
"attemptNumber": 0,
"objectId": 1551,
"propertyName": "firstname",
"propertyValue": "Roberto",
"changeSource": "CRM_UI"
},
{
"eventId": 3001923471,
"subscriptionId": 3104,
"portalId": 22235544,
"appId": 43891,
"occurredAt": 1657014641540,
"subscriptionType": "contact.creation",
"attemptNumber": 0,
"objectId": 1551,
"changeFlag": "NEW",
"changeSource": "CONTACTS"
},
{
"eventId": 1561194721,
"subscriptionId": 3107,
"portalId": 22235544,
"appId": 43891,
"occurredAt": 1657014641516,
"subscriptionType": "contact.propertyChange",
"attemptNumber": 0,
"objectId": 1551,
"propertyName": "lastname",
"propertyValue": "Hernandez",
"changeSource": "CRM_UI"
}
]
The payload of second webhook contains array of one object of subscriptionType contact.propertyChange for property email [ { "eventId": 622558465, "subscriptionId": 3105, "portalId": 22235544, "appId": 43891, "occurredAt": 1657014641540, "subscriptionType": "contact.propertyChange", "attemptNumber": 0, "objectId": 1551, "propertyName": "email", "propertyValue": "roberto.hernandez@example.com", "changeSource": "CONTACTS" } ]
As these webhooks are within negligible time difference and on event of same contact creation, it leads to creation of duplicate contact in our system.
It looks to me like the Webhook is firing for a new Contact:
"subscriptionType": "contact.creation"
AND each property change:
"propertyName": "firstname"
"propertyName": "lastname"
"propertyName": "email"
Which would give you 4 json objects (as expected). I would use the "subscriptionId" in your code to handle the data. From memory a "change" is the same as "creation" – in other words if you only have "propertyChange" subscriptions they will also trigger when a new Contact is created. You will need to run tests to double check this theory.
Thanks for replying. I was not expecting a reply in this post as the existing reply was unexpectedly accepted as a solution itself.
The issue is neither that the two webhooks are triggered nor that it sends payload for contact.creation and contact.propertyChange. The issue I face with above way the webhooks are triggered is that - as the two webhooks are triggered within negligible time difference, both of the webhook were running process simultaneously to create a contact - which eventually lead to duplicate contact.
Could you please elaborate how we can avoid this with subscriptionId?
Typically we set up a Job Queue to do the work after we've sent a reply to HubSpot. THis alllows us to reply to HubSpot as soon as we can when we receive the information.
Receiving more than one webhook for same event on Contact Creation
SOLVE
Hey, @Setmore👋 Let's see if we can get the conversation started for you. @Teun@Mike_Eastwood, do you have any experience with the issue @Setmore is describing?