It adds a tremendous amount of complexity to all of your services, where now all of your services will need to maintain the ability to answer the question 'what was your state at this point in time.'
It makes it extremely difficult to support new webhooks, and honestly in my experience nobody actually ever queries for the historical data anyway. My opinion is that webhooks just aren't the correct approach to take for anything absolutely critical. They're a great addition for stuff outside the critical path where delivery is not essential, and as long as you stick to that paradigm you can dodge these issues entirely.
Re 'thin webhooks' which require hydration:
- subject to either complexity to support historical state (e.g. what was the state at the point in time when the webhook was issued) or race conditions (two things happened, but your API only gets current state)
- honestly none of your consumers want this - they're gonna be like 'why do i have to also query an API why can't you just hydrate the payload in the webhook body'. Guaranteed.
- still probably the correct solution if the data is super private and you want to be extremely cautious about issuing webhooks for it
source: worked exclusively on webhooks and similar eventing stuffs at place you've heard of for a few years