• by simonw on 12/7/2023, 8:37:24 PM

    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/...

  • by dwb on 12/7/2023, 8:21:46 PM

    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

  • by AustinBGibbons on 12/7/2023, 11:35:30 PM

    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.

  • by kisamoto on 12/8/2023, 8:48:04 AM

    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?

  • by ultrasaurus on 12/7/2023, 9:43:17 PM

    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.

  • by paulddraper on 12/7/2023, 11:31:41 PM

    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.

  • by stephen123 on 12/7/2023, 9:21:54 PM

    Looks great.

    What are people using to store and send retries?

  • by pyrolistical on 12/7/2023, 8:18:24 PM

    > 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.

  • by theogravity on 12/8/2023, 8:49:16 AM

    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.

  • by yawboakye on 12/7/2023, 8:59:20 PM

    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?