From Sleeper to Slack: Automating Fantasy Football Results with Itential

In the year 2014, Fantasy Football was reaching critical mass in the zeitgeist due to endless TV Commercials, daily fantasy betting, and even TV sitcoms (see “The League”… no really, go watch it if you haven’t). That also happened to be the year that I walked away from Fantasy Football permanently. I had grown tired of years of meticulous management and research, only to have injuries or poor performances bring a loss against my league’s “auto-drafter”. If you aren’t aware of what an “auto-drafter” is, they are someone that lets the computer pick all of their players for them during the Fantasy Football Draft.

So, last year, when our CEO walked into the office complaining of a 4-point loss to the company league’s “auto-drafter”, I put aside my initial reaction of empathy and instead decided to use our product, the Itential Automation Platform (IAP), to post the scores to a company-wide Slack channel for everyone to see.

I logged into my local IAP and used the workflow canvas to begin laying out the steps that I needed to perform to get the scores data out of Sleeper and into Slack. Using stub tasks made it easy to see the steps and plan my workflow before diving in:

At this point, I knew that this might become a good case study in automation, so I used the timer on my phone to start timing myself on how long it took to research and create each portion of my workflow.

A quick Google of “Sleeper Fantasy API” returned a link to the documentation for the official Sleeper API. It turns out that they have a wonderful free API that is unauthenticated, because it is read-only.

I knew this would be a great candidate for an IAP Integration Model, which uses OpenAPI models (formerly known as Swagger) to interact with APIs. I Googled “Sleeper Fantasy OpenAPI” and “Sleeper Fantasy Swagger” to see if an OpenAPI model was available to use, but alas there wasn’t one.

Luckily, that’s only a small hurdle. While many platforms that our customers would normally integrate with have published OpenAPI models, for those that don’t, it’s a straightforward process to build one from their API documentation. I opened up Visual Studio Code and began writing my own by referencing their API docs and the OpenAPI specification doc, which took me just under 14 minutes.

I converted the example payloads they had for API responses into JSON Schemas using JSON to JSON Schema Builder. Then, I imported the OpenAPI model into IAP as an Integration Model and created a new Integration Instance. This took less than a minute, but I did almost forget to go into the Authorization menu and give myself permission to access the Integration.

Navigating back to the workflow canvas, I created a workflow to test my Integration with all of the methods that I knew I would need.

Integration methods return a response object that wraps the actual API response data, resulting in the need for some basic query tasks after each Integration method task to extract the data we need. In the future, we plan to streamline this processes further by adding a feature that allows users to directly access any of the data points individually on subsequent tasks, instead of the entire response object. This means fewer query tasks and less clutter for all workflows that use Integration methods.

I ran my workflow and viewed the result:

In order to retrieve all of the data I needed, it was necessary to make 4 individual API calls to the Sleeper API, which appear as tasks in my workflow. While this may not be optimal, the good news is that the Sleeper API response is fast, as the 4 API calls and 3 query tasks took less than 1 second total for the IAP Workflow Engine to process. This helps illustrate how efficient API calls can be in automations over manual methods.

At this point, I had run into a conundrum. How do I turn 3 different JSON payloads into a single message text (string) that can be posted to Slack?  Even worse, the matchups API response was difficult to work with as it didn’t even have the data for a single matchup together, but instead had an object for each roster with a matchup id in it. I was going to have to put together the matchup objects, look up the roster id in the rosters API response, and then look up the user id from the roster in the users API response. Luckily, we have a tool that can do all of that and more when dealing with JSON, called JSON Schema Transformations (JST).

Creating the JST took less than 25 minutes. While it is always possible to write code to manipulate data, JSTs bring significant benefits. A JST is portable and can easily be moved between IAPs when you need to promote an automation to production. JSTs are also visual, which makes the process of understanding everything easier for team members who are not programmers. It’s a streamlined, more repeatable way of transforming data than building something from scratch for every job.

In order to post the message to Slack, I knew that I would need an Adapter in IAP. Searching the Itential Open Source documentation lead to a Slack Adapter that I downloaded and added to my IAP. This only took a few minutes, but I also had to create a Slack App, and then reach out to our IT team to get a Slack App approved in our Slack Workspace. Creating and configuring a Slack Adapter instance took a few minutes as well.

Once the Slack Adapter was online, I added a task to my workflow to post the message to a channel and hooked up the output from the JST task. Now that I had a working workflow that would retrieve all the data from the Sleeper API, format the data into a message, and post that message to Slack, I set about creating an Automation in IAP’s Operations Manager to schedule the workflow to run every Tuesday morning at 2 AM EST.

I created a new automation job and added my workflow. Then I created a Trigger of type “schedule” and set it to run on Tuesday morning at 2 AM (automation Jobs can also be triggered via network or system changes, manual form submissions, and API calls from other systems or users). I configured the Trigger to repeat every week so that everyone at Itential would always be aware of who won and who lost — ensuring nobody could hide from a loss to the auto-drafter!