Building Slack Integrations for Reclaim Hosting

Building Slack Integrations for Reclaim Hosting

For that past few months I've been dipping my toes in and out of the water of a Slack account I setup for Reclaim Hosting. When I went full-time back in January it seemed like perhaps a better way for Jim and I to stay in touch about what we were doing. But old habits die hard and we tend to still use Twitter DMs and email for a lot of that correspondence. That being said I've kept that app on my computer because of two integrations I added early on that proved useful.

I added the Twitter integration to notify a channel of any interaction between @ReclaimHosting. While I still use apps like Twitter for Mac to correspond with folks there it's nice to have a quick archive of that stuff in Slack as well. I also added an integration with Intercom, our support system (we were previously using Zendesk which also wrote to Slack) to have ticket notifications come into a support channel there. I still get all of these notifications by email for now because sometimes I'm in multiple places, but I can start to see how pushing more notifications to Slack channels could help filter and, well, channel that information to places where I'm not the only one receiving them and others can act on them. And even though we're only a team of 2 today, if history is any indicator even that could change a year from now so setting up processes today to share this information is a good thing in my eyes. I've also found notifications come to Slack typically much faster than either email or native notifications on the phone, which is a nice perk.

So Jim and I were taking a fresh look at our Slack setup today and I had recently begun to look at Slash Commands. Slack has a few built-in commands for doing a variety of things like setting reminders, switching channels, or even subscribing to RSS feeds. But one really cool thing is that you can build your own commands that get sent via the Slackbot to a script and return information. So my goal today was to try building one that Jim and I had a need for, finding out what server a particular user is on. When we began Reclaim Hosting almost 2 years ago we had a single server and life was much simpler. Today we have 3 servers for shared hosting with probably a 4th being provisioned soon, not to mention servers for a variety of other institutional accounts. When we receive tickets from folks needing help the first piece of information we go looking for is which server they're on to troubleshoot. So I figured it would be cool to have a command that we could send a domain to and get back the server it's hosted on.

WHMCS, the billing system we've used since day one, has a decent API for getting some of this information remotely and it turns out Slacks system for building slash commands is pretty straightforward. You tell them what you want the command to be (in this case we chose /whatserver) and the location of the script and they will simply forward on the text that comes after the command to the script as a POST request. The script can parse it however it likes and whatever gets printed from the script gets sent back to the Slack channel as a private message to the person who issued the command. Building the script required just two API calls, one to receive information on the requested domain and one to take the user ID from that first call and print out each hosting account the user has. With some formatting of the final echo I'm able to do something like this:
Screen Recording of /whatserver

Now it's not perfect because it's pulling all "products" for a user and in my example there are a few SSL certificates. I need to narrow it down to only display hosting accounts but that's just massaging the data. And ideally I might be able to get information like this directly from our DNS rather than through the billing system (which isn't necessarily going to show information about addon domains registered elsewhere and other nuanced scenarios like that). But for a first pass this will greatly help Jim and I be able to jump into the server of whichever user we're looking for. Because our ticketing system does display user ID I made it optional to throw a number at the same command and get the same display rather than even having to know the domain.

Some changes I'm looking at making are to generalize this into a single command for multiple types of information. I could see a /whmcs command that pulls all types of information about a user on the fly, not just a single-purpose script like this. I'm going to work on that using a WHMCS PHP library as a base and release the code for that in case it's useful for others, though I recognize this is very much a niche thing. As we start to play around with integrations like this I'm also realizing that building small purposeful tools for our business could really save us a bunch of time and it's the not-so-secret way that we're able to remain lean and build a company supporting thousands of people today. I'm starting to find comfort in coding and the idea that if we need something and it doesn't exist yet, we might be able to build it.


I've added an example script to GitHub to show how this works. This script will print out a list of domains by sending it an email address. I've also put a lot of comments in it to show what's happening.