Standard Webhooks: open-source tools and guidelines for sending webhooks

  • This is useful. I've been part of a team implementing webhooks in the past and there are a lot of difficult details you need to get right - things like responsible retries, authentication, thin-vs-fat hooks and server-side request forgery.

    This document covered all of them. Here's the SSRF bit for example: https://github.com/standard-webhooks/standard-webhooks/blob/...

  • I wondered, "whose standard?", and was pleasantly surprised to find a list of real names [1] on the website. Nonetheless, I do bristle at the semantic weight of the name despite the fact it's not attached to a relevant existing institution.

    [1]: https://www.standardwebhooks.com/#committee

  • Good sign to me is one of the steering members is Tom Hacohen founder of Svix (webhooks-as-a-service). We're adopting them where I work and everything from them has been solid. I know he's seen a lot of different use cases and will have good consideration for the schema they define in their spec file.

  • I'm curious as to why webhooks are becoming a defacto standard for triggering events between isolated systems.

    Why not have a dedicated event bus (could be - but not limited to - kafka, NATS etc.) where remote systems connect to dedicated event queues? Push a message onto the queue which is picked up by the remote system.

    Authentication is handled by the event bus which can also act as a storage for message (re)delivery. Partitioned by customer ID for separation of concerns etc.

    Anything immediately obvious why this wouldn't be a preferred option or is it because HTTP is just easier to implement across systems?

  • This is also a really good summary of "what to think about while implementing webhooks" -- personally I wish we had thought of doing "thin" webhooks in an implementation I was a part of.

  • Question:

    Why do so many webhooks use HMAC signatures for authorization?

    For everything else in APIs, people are perfectly happy to use API tokens/secrets directly in headers.

    Why don't webhooks directly share secrets, instead of HMAC signatures?

    Like, I understand the advantages of HMAC, but for some reason it seems to be that webhooks are unique in their usage of it.

  • Looks great.

    What are people using to store and send retries?

  • > While this specification does not dictate the structure, or impose any requirements, on the shape, format, and content of the payload it does offer recommendations

    Too loose to be a standard but better than nothing.

  • The signature format is just weird. Why not include it as part of the request headers?

    Edit: It seems to also have a header version. Not sure why there's two different ways to pass a signature here.

  • webhooks were a phase we should have passed by now, not try to entrench with some standard. it’s a broken/obscure implementation of full duplex communications between two systems but thought up as if it were a luxury, auxiliary system whose downtime we should be able to tolerate. if we’re required to survive downtime of a webhook system, i think we’re right to ask: why are they there in the first place?