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).