Hubspot Webhook Event Spam

[CForrest5]

Can someone explain why Hubspot sends multiple webhook requests on deal creation? Why would anyone need to know that yes you created an object with this ID and then proceed to spam the backend with object.propertyChanged events for the fields that were entered during creation. This makes zero sense. Not only that sometimes those requests come out of order meaning the object.propertyChange can come before the create and in seperate requests...

WHY? Just send one request for object.creation and i'll make a request to pull it from the CRM...

Please explain. This causes our backend to do unnecessary work?

You could at least group all those events and send them once and allow me to aggregate and persist them on our side...

[HubDoPete · Accepted solution]

Hi @CForrest5 and thanks @BérangèreL 

The article by @Mike_Eastwood is excellent, but it relates to the need to respond quickly to HubSpot webhooks with a success 200, to avoid HubSpot sending duplicate retries.

Christopher, for the issue you describe, it sounds like your Webhooks subscription includes multiple event types, including "Property changed". That is why you are seeing Object Created and also Property Changed.

If your app also needs to know when Deal properties are changed, subscribe to that event using a different webhook endpoint.

tl:dr; Amend your webhook subscription only to object Deal, event: "Created"

best

Pete

[BérangèreL]

Hi @CForrest5 and welcome, we are delighted to have you here!

Thanks for reaching out to the HubSpot Community!

I'm sorry to hear about your experience regarding this.

I would like to apologize for the frustration, data issues, and business impact this has caused.

I have found for you the solution from @Mike_Eastwood on a similar thread "Deal webhooks triggering multiple times." that might help you.

To our Top Experts: Hi @zach_threadint, @HubDoPete do you have additional information/suggestions you'd like to share to help @CForrest5, please?

Also, I'd recommend sharing your valuable feedback by submitting the HubSpot Developer Feedback Form so that the Team can be aware of this and get back to you about the reason behind this.

Have a great day and thanks again for sharing your feedback with us. It helps improve HubSpot for our whole Community.

Best,
Bérangère

[HubDoPete · Accepted solution]

Hi @CForrest5 and thanks @BérangèreL 

The article by @Mike_Eastwood is excellent, but it relates to the need to respond quickly to HubSpot webhooks with a success 200, to avoid HubSpot sending duplicate retries.

Christopher, for the issue you describe, it sounds like your Webhooks subscription includes multiple event types, including "Property changed". That is why you are seeing Object Created and also Property Changed.

If your app also needs to know when Deal properties are changed, subscribe to that event using a different webhook endpoint.

tl:dr; Amend your webhook subscription only to object Deal, event: "Created"

best

Pete

[CForrest5]

The UI only allows us to create a single webhook and subscribe to events that are then sent to a single URL?

How do you create multiple webhooks?

The events are aggregated by object type.

[HubDoPete]

Apologies Christopher - yes, for each HubSpot App, all webhooks are sent to a single endpoint. There isn't a way to prevent property change webhooks from firing, but I can see why you prefer not to receive "property changed" webhooks related to a create event.

I assume you need to know when deal properties are changed, or you would have removed that subscription.

Alternately, here to reduce processing I would add a dampener mechanism on your webhook endpoint to dismiss "property changed" webhooks for Deal Object IDs created in the last X seconds.

We have had to implement "webhook dismiss" code for similar use cases.

best

Pete

[CForrest5 · Accepted solution]

Hey Pete,

Yes that's what I've done.

For anyone else who happens across this post this was my solution.

When the webhook request is received by the backend I first seperate all of the events into create, update and delete events.

To do this first simply filter out all events from the request by the subscription type for create (e.g object.create).

Then for property changed events where there is a create event with that object id exclude those from the list of update events to be handled.

For delete simply just filter by subscription type for delete as they come in as a single event as do property change events.

Finally handle each event for each event type and do your insertions, updates and deletes in your DB and send back a 200 to Hubspot.

If your requests would likely take longer than 30 seconds (mine won't) then I suggest you immediately return 200 to Hubspot to prevent retries and keep track of events and have the ability to replay failed events if required.

It's not perfect and unfortunetly Hubspot will send additional requests shortly after the initial request that relate to the create which may result in a record not found error which I simply allow to happen and catch to prevent my backend from crashing.

I found this to be the most efficient way to handle the webhook events in ExpressJS. 

Unless the team at Hubspot have an actual use case for this behaviour I'd ask them to reconsider the sending of those additional events. I can't understand why when the create can notify us to simply pull the deal from the CRM when received. There is potential for those additional events if not handled correctly to spam/overwhelm a backend if mass failure occurs and the requests are retried on a large scale (e.g someone messes up the logic for handling updates).

[HubDoPete]

Well done Christopher, that works well for segmenting the batch of webhooks to make local decisions.

I hope that HubSpot does not stop sending webhooks for property change subscriptions when an object create webhook subscription is added. That would break apps that trigger on new or modified objects, as soon as the critical property is "Known". As it is today, processes can remain loosely coupled.

Thanks for sharing your webhooks segment & process flow!

best

Pete

[CForrest5]

Sorry yes not introducing it as a breaking change 😅

Maybe in the form of a toggle to silence subsequent requests on update which would result in a single event per create similar to the behaviour of update / delete.

Thank you for your support.