Building a Slack Bot with the Twitch API and Postman

The development process

Introducing the Twitch API

Everything from the most popular titles and box art to streams and streamers’ information can be accessed through the Twitch API. We can use this API in Postman as well. For example, the endpoint /games/top will return the most popular games, and /streams will return information on a streamer.

Under the Twitch API reference, I found that Twitch uses OAuth 2.0 for authentication flow, which is supported by Postman. After registering an app and filling out the data in Postman, I obtained an access token, configured the authentication in Postman, and began executing requests to receive data from the Twitch API. There are a ton of endpoints, which cover almost everything you can see and do on Twitch.

Now that I had access to the Twitch API, I had two questions:

• How could I connect Slack to Postman?
• How could I automatically run a request or string of requests in Postman when a specific event occurred?

Automating with webhooks

At this point, I was aware of Postman monitors. They run an entire collection of requests on a defined schedule. The challenge was figuring out how to run only specific requests, and to trigger this on an event instead of a set schedule.

Digging deeper, I came across Postman Director of Developer Relations Joyce Lin’s Level Up video on Postman webhooks. I learned that webhooks are actually just Postman monitors underneath. Meanwhile, Slack allows you to attach a webhook to a slash command. This means that I can run a Slack slash command, and Slack will trigger the webhook link attached—which triggers a Postman monitor that then will run a Postman Collection. Now the problem is, how do we run only the correct requests for a given slash command and nothing else? Postman monitors will run an entire collection of requests, but what about when we need to run only one or two specific requests?

Enter: postman.setNextRequest()

Before I did this, I needed a way to send messages to a Slack channel after processing a command in Postman.

Setting up Slack commands

Using the magic of code, I knew there was a way to change the execution flow on requests in Postman. I could check what command was being run from our webhook and then direct Postman to the proper request for that command. If I set the next request to null, then I could end execution. This was the missing piece to the puzzle.

To connect Slack and Postman, I needed a two-way connection. One side was for triggering a Postman monitor when we ran a Slack command using the Postman monitor webhook. The other was for sending a response message from Postman to Slack using a Slack webhook.

A quick Google search helped teach me how to send Slack messages from Postman. I quickly generated a Slack incoming webhook URL that I could make POST requests to in Postman. With the help of Slack’s Block Kit Builder, I was able to easily design what the message output of my commands would look like in Slack.

Similarly, I was able to make a request to the Postman API to create a webhook that will trigger the attached Postman monitor to run when a slash command is run in Slack. After creating a slash command in Slack for our “Get Game” command and attaching our Postman webhook to it, it was time to put together the command logic in Postman.

Pre-request scripts and testing

You can think of requests in Postman as a three-step process:

1. The pre-request script code is run.
2. The actual web request takes place.
3. The post-request script, or test scripts, are run.

When my monitor ran, I needed to ensure I still had a valid auth token for Twitch and, if not, refresh it. I also needed to look at what command had been triggered, which could be found in the globals.previousRequest object.

From there, I could store variables that I would need such as the command’s name and its parameters, if it had any, as well as then direct to the correct Postman request that contains the corresponding command logic. All of this was easily done in the collection-level pre-request script so that it ran first, every time a command is issued.

From this point, the core of the bot was complete. All that remained was building out my command logic, fetching data from the Twitch API, and organizing it in a way that was readable for Slack. After adding some documentation to explain how things worked and cleaning up private tokens/keys, I was ready to go public and demo my creation in front of the Postman team.

Key takeaways

While building this bot may have sounded easy, and my demo video made it seem like a breeze, it actually took ages.

I went through three iterations trying to figure out how to best organize the command switching logic. Handling auth refresh tokens took some practice, but I was able to find an excellent example from cloud architect Allen Helton that helped explain how I could achieve this in my pre-request script.

Postman monitors only have access to the initial value field of collection and environment variables, so I needed to be careful with security and using public workspaces. You should never store access tokens or keys in initial variables! It’s also important to make sure you are not calling the same request inside of postman.setNextRequest(). Otherwise, you will very quickly blow through your monthly monitoring usage limit of a thousand requests on the second day of the month like I did.

The biggest challenge was trying to handle asynchronous code in a more synchronous manner inside of the “Top Games” command, where I made an external API call within a request and needed to wait for that data to return. Thankfully, Postman Technical Lead Sivcan Singh came to the rescue with an Async Operations collection, and I was able to overcome this final hurdle.

If you’re interested in learning more about this project and trying to create something with it yourself, head over to the Published Postman Templates workspace to fork my collection and follow the “Getting Started” section of the documentation.