[jarcoal]

Sort of disagree with the send-everything-in-the-payload approach. It opens your system up to all sorts of weird edge case bugs like receiving hooks out of order which could mean stale data is considered fresh. It also means you have to care a lot more about verifying the authenticity of the request.

[beachy]

Agree. Its better to use webhooks as a pure signal that something has changed, and then in the case of update or insert, have the client pull whatever they want using normal API.

Otherwise, you end up in a descending vortex of madness trying to specify some protocol whereby the client can specify in advance which properties they care about.

[draaglom]

This is correct, and important.

Webhook payloads need to be logically monotonic[0]; this probably means either:

- having a lamport-clock timestamp for each payload so you can entirely discard older payloads in favour of new ones

- a well defined / consistent "merge" function over the subset of the payload you care about (e.g. maybe you know a customer's state can never go back from "registered" to "guest")

[0]: http://bloom-lang.net/calm/

[nimblegorilla]

"trust but verify"

Sometimes you want to ignore webhooks based on the payload (or put them into a different queue). It's faster to do that if you get the payload up front.