Best practices for tracking duplicate webhooks

I was wondering if there’s an accepted way to handle duplicate hooks, currently I’m hashing the response data & storing that in Redis & checking against it to see if I’ve already handled a hook.

I’m just confused as there seems to be no identifier to say “these hooks were meant to do this action on this object” that we can use to check for duplicates, since each webhook/attempt has a unique identifier.

e.g. a video.asset.errored has happened twice in the same day on the same object - so they’re not duplicate hooks, but have duplicate data. Maybe I’m missing something here - thanks in advance for any pointers.

[dylanjha]

Hi @cwqt I agree it’s an important issue. We just try to keep the issues in this repo specific to the node SDK.

I double checked this functionality, duplicates and re-attempts will have the same top level id (which is a unique identifier for the event). Thanks for the docs feedback, we can definitely make that more clear, thank you!

[cwqt]

Appreciate the write-up, but I think this is an important issue that shouldn’t be sidelined into support channels, especially when money is on the line depending on if a hook is accidentally re-handled.

If duplicate webhook notifications are sent for an event (again, this should be incredibly rare), the event’s id should be the same in both request bodies.

Right okay, that’s just not made clear in the documentation, it’s really ambiguous that & not clear that duplicate webhooks (not a re-attempt) will have the same Id, even now you say they should, not they will …