Ask HN: Standard for webhook source IP declaration?

I would encourage you to provide a stable URL where the IPs can be fetched by an automated process, regardless of whether you also provide a "human readable" version. Even just a text file with addresses would be fine.

It's not that you should expect to be changing them very often but it's also extremely unlikely someone using your service is going to manually monitor whatever published list you have - whereas a firewall can be set to fetch your list once a day and will therefor get any changes you need to make, automatically.

I think the standard is to publish the IP addresses. I understand why companies request this, so they can open their firewalls to those addresses, but in terms of security the real answer is to use bidirectional mTLS, so that you just need to publish your public certificate rather than (or at least, in addition to) an IP address. Unfortunately, mTLS deployment is fairly complex and isn't a great solution for webhooks unless you control the library code on both ends (i.e., you're publishing client libraries for receiving the webhooks), or if you make it an opt-in feature for extra security. Otherwise the simple use case of "just set up a receiving HTTP server" becomes much more complicated and adds undue friction for developers implementing code to receive the hooks.

This is what we do at Svix: https://docs.svix.com/receiving/source-ips

I've seen other companies (e.g. Stripe) also offer it via JSON, but I personally think it's not that important to provide it in a machine readable format if you don't plan on changing it; which you shouldn't as it'll break integrations. You should only add new IPs that can only be allocated to new customers.

P.S, if you'd like to start sending webhooks, you should probably check out Svix: https://www.svix.com

This is how Amazon does it: https://aws.amazon.com/blogs/aws/aws-ip-ranges-json/