Webhooks do’s and dont’s: what we learned after integrating APIs
1–10 of 83 posts
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#2It's also really handy when API providers give a nice webhook UI that lets you view and resend webhooks during development.
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#3This is going to sound bizarre, but why do webhooks and not just an AMQP queue? I get that receiving HTTP POSTs is easier, but it just seems better to setup a publisher/subscriber relationship. That way, if a subscriber goes down, they can always catch up. And publishers can allow messages to sit in the queue with a TTL and max_size. It seems like a win-win for everyone.
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#4This is going to sound bizarre, but why do webhooks and not just an AMQP queue? I get that receiving HTTP POSTs is easier, but it just seems better to setup a publisher/subscriber relationship. That way, if a subscriber goes down, they can always catch up. And publishers can allow messages to sit in the queue with a TTL and max_size. It seems like a win-win for everyone.
Though this is an approach worth considering for a bunch of local services, at least a subset of them, I don't see it working with 3rd party APIs. Consider something like Stripe — it is probably far more straightforward to invoke some HTTP endpoints, than to set up a huge infrastructure with millions persistent client connections.
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#5I think the "securing webhooks" section is missing some critical tips that we've learned in production.
1) Resolve the DNS of the webhook URL, and compare all returned addresses from that resolution against an IP blacklist, which includes all RFC1918 addresses, EC2 instance metadata, and any other concerning addresses.
2) Even though it seems like you'd want to, do NOT blindly return an unexpected response to the person configuring the webhook. Say there was an error, what the code was, etc, but returning the response body means you basically just gave someone curl with a starting point on your network (see 1 as well)
3) Find ways to perform other validations of those webhooks. Are the URLs garbage? Are they against someone else's system? Create validation workflows that require initial pushes to the URL with a validation token to be entered back into your system, like validating an email address by clicking a link.
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#6[deleted]
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#7This is going to sound bizarre, but why do webhooks and not just an AMQP queue? I get that receiving HTTP POSTs is easier, but it just seems better to setup a publisher/subscriber relationship. That way, if a subscriber goes down, they can always catch up. And publishers can allow messages to sit in the queue with a TTL and max_size. It seems like a win-win for everyone.
Though this is an approach worth considering for a bunch of local services, at least a subset of them, I don't see it working with 3rd party APIs. Consider something like Stripe — it is probably far more straightforward to invoke some HTTP endpoints, than to set up a huge infrastructure with millions persistent client connections.
Agreed. I believe that AMQP connections are best suited for wide and articulated local environments. Moreover REST HTTP endpoints are today's esperanto :)
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#8I think the "securing webhooks" section is missing some critical tips that we've learned in production. 1) Resolve the DNS of the webhook URL, and compare all returned addresses from that resolution against an IP blacklist, which includes all RFC1918 addresses, EC2 instance metadata, and any other concerning addresses. 2) Even though it seems like you'd want to, do NOT blindly return an unexpected response to the per…
The entire guide seems mostly consumer-centric: What do they as the one being called want, sender-side concerns are missing entirely.
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#9It's also really handy when API providers give a nice webhook UI that lets you view and resend webhooks during development.
True. Also having a sample request at the very beginning is useful so you don't have to find a way to trigger the event by clicking around on the product UI.
Re: Webhooks do’s and dont’s: what we learned after integrating APIs
#10I think the "securing webhooks" section is missing some critical tips that we've learned in production. 1) Resolve the DNS of the webhook URL, and compare all returned addresses from that resolution against an IP blacklist, which includes all RFC1918 addresses, EC2 instance metadata, and any other concerning addresses. 2) Even though it seems like you'd want to, do NOT blindly return an unexpected response to the per…
The entire guide seems mostly consumer-centric: What do they as the one being called want, sender-side concerns are missing entirely.
Yes but that's why you build webhook for, to let people consume your content. I think DX is critical today and big companies can afford to do the heavy-lifting. As I mentioned in the Subscription Expiration paragraph I totally get Microsoft's reason to put a 72hrs expire date on subscriptions but it adds some friction on the consumer side.