Comment on: Give me /events, not webhooks
I prefer the idea of using empty webhooks. The message body contains the id of what changed, and a status like "NAME_CHANGED", but not the data that changed. Then paired with the API to retrieve the real data.Webhooks shouldn't be assumed to be reliable, and that should be clear in the API docs. You can perform your own lookup to these data APIs to confirm the source of truth in your own data
Comment on: Give me /events, not webhooks
I'm all for /events and appreciate the platforms with good support. However, we live in a world where people build event-driven and serverless architecture. The use cases go beyond replication, and webhooks are here to stay.The thing is, you can get the best of both worlds by using webhooks in conjunction with /events reconciliation. That might seem like a lot of work, but that's what tooling is for. Webhooks are complicated to handle reliably, but it's a problem that has good tools the same way sequin (and many others) is helping developers solve the replication problem.For webhooks, hookdeck