How Edgility solved their webhook routing pains

Evan is the Lead Developer at Edgility. He and his team are responsible for the overall product. This includes marketing SMS, transactional SMS, confirmation SMS for developers, and 2FA. 

Evan and his team receive webhooks from multiple telecommunication carriers. Their problem occurred whenever they needed to change a webhook URL, as the telecommunicator would take 1 to 2 weeks to input the changes in their system.

Unfortunately for Evan, telecommunication companies don't have a control panel to switch URLs, like many API companies do. Instead, Evan has to open a ticket with customer service, which is a long and arduous task. It's a time intensive activity for the carrier, and has a big impact on the developer team's ability to work on new features.

A while ago, Evan found Hookdeck while browsing Hacker News. He signed up using his personal email, thinking it was a cool service but not relevant to him at the time. When he was dealing with webhook related issues, he remembered Hookdeck and quickly went back to find the thread on HN using the Algolia search.

Webook routing

First, Evan was trying to solve how Hookdeck could help him avoid dealing with the long wait times associated with tele carriers updating his webhook URLs. He was looking for a solution that would allow him to provide permanent webhook URLs and make all the routing changes within the same product.

With Hookdeck, Evan was able to give each of his carriers a permanent webhook URL and work the routing rules within Hookdeck.

The process looks like this:

1. When there's a new endpoint, Evan configures a new destination and connection in Hookdeck.
2. Then, he tests his integration with production data.
3. When it's ready for production, he archives the previous connection.

Voila! Webhook routing without interacting with the telecommunication carriers!

Essentially, Hookdeck is acting as a message queue when it comes to routing webhooks from the producers (telecommunication carriers) to the right consumer (Evan's endpoints).

‍

‍

Error recovery

Webhooks fail silently. It's not as obvious as a customer saying they didn't receive "X," it becomes harder to identify and to fix.

A lot of webhook providers won't actually send you an alert when a webhook fails. Some webhook failures are harder to keep track of, for example a validation error. Unlike 500 errors, where you are likely to have systems that are already monitoring them in place, an authentication error is more likely to fail silently.

By putting his integrations on Hookdeck, Evan benefited from Hookdeck's constant monitoring of webhooks. He soon realized that receiving alerts each time a webhook fails and having access to manual retries were key features that helped his team recover from issues before their customers noticed anything.

Example

Evan and his team were able to recognize that a bug was introduced that would impact the webhooks routing for 3 customers. Evan received alerts, and then went into Hookdeck where he could easily search for and identify the failed webhooks. He quickly started to troubleshoot the issue and deployed a fix in record time. Then, he manually replayed the failed webhooks.

All of this before the customers even had the chance to see any of the bug's impact!

Before Hookdeck, the same scenario would have looked like this:

1. Evan and his team wouldn't have known about the bug, and most likely would have been asked by their customers why some of the SMSes weren't working.
2. He would have pulled out all exceptions from Bugsnag (his failed webhooks are treated as exceptions on Bugsnag to have a degree of visibility) and combed through them to identify the error.
3. If he had been unlucky and the failures weren't logged as an exception, then he would have to try his luck and find the webhooks in the logs of his cloud provider (which isn't as easy as it sounds…).
4. After troubleshooting his error, he would have to write a script to pull the webhooks based on a time window and replay the ones that failed.

Evan considers Hookdeck a crucial part of his stack.

Hookdeck was able to solve his biggest pain by removing his back and forth with the carrier. The Edgility developers now control everything related to their webhook routing, which saves them many hours of precious development time.

After transitioning all their webhook integrations onto Hookdeck, they have a lot of confidence in their ability to quickly respond to and fix any errors that might occur. In other words, Evan and his team can now deliver the delightful experience that Edgility’s customers expect.

I've been recommending Hookdeck to tons of devs. The product is so useful and their team is extremely responsive. The experience has been great.