Skip to content

OAUTH with Alteryx

How to?

This post will revolve around the process of authenticating to get data through APIs – In this case Spotify.

First of all, a new macro has been added to the Inviso Macro Pack which makes the process of authenticating with Spotify super simple.

You are more than welcome to download it, use it, open it up and reconfigure it whatever way you see fit.

The setting

My favorite Alteryx tool, hands down, is the Download tool.
However to use the download tool, we often need to authenticate in strange and difficult ways.

In this post I will go over how to Authenticate with the Spotify Web API

The Spotify web API is great. It allows you to do endless cool stuff!
Step by step I will walk you through the process of getting from an idea to having the data accessible and ready.
The concepts we will go through are quite general – So once you’re able to authenticating with Spotify, most other APIs should follow easily.

Spotify provides the following schema for the different ways to authenticate and essentially access their data.
(The green circles are drawn by me):

What I read from the table above is quite simple – If you want the full and most flexible access, you will have to gain an Authorization Code.

And yes, you guessed it, the Authorization Code has the most difficult process of the four ways.

So how does Spotify tell you to get the token – Through the diagram below:

(A side note for the nerds, I included, this is happening through what is called OAuth, which is just one of many ways of authenticating with APIs)

7 steps, 7 steps… At first glance this can easily seem quite overwhelming, but after having seen a guide like this more than once, it doesn’t seem as frightening – They **all **look the same. Basically you are asked to do two things. Firstly handshake (say yes to share your data through the API) and secondly refresh to keep the yes alive.

So how is this actually done?

1. Register as a developer here

First step is to register as a developer and creating an app.
This is simply done so that (in this case) Spotify can keep track of the use of their API and provides you with some statistics about what is requested through the API.

2. Get the user to allow access

The entire reason we are authenticating in the first place is to access data. Whomever we are interested in gathering data from, be that our own data or someone else, we need to have been given a thumbs up to access the data.

This is done by directing the user towards a URL.

In the Spotify case it means directing the user towards AND some more that says something about what access you are asking for and who you are.[FILL IN]&scope=[FILL IN]&redirect_uri=[FILL IN]

The above is the URL the user is to be directed at.
It consists of two parts:

  1. The endpoint
  2. The parameters
    • response_type
    • client_id
    • scope
    • redirect_uri

The two are separated with a question mark “?”

These parameters can differ from API to API, but in the Spotify case these are the required ones.

  • response_type should in this case always be code.
  • client_id is an identifier telling who are asking for access (this being us) and can be found on the developer site.
  • scope is the level of access we’re asking for i.e. what kind of data, how personal and so on.
    • A list of the different scopes for Spotify and what they give access to can be found here
  • redirect_uri is where Spotify will return the answer to our request, in this case a code we can use to authorize.
    • In the ideal setup a webpage is configured to handle this and retrieve the code.
    • Is this needed? No. Simply using http://localhost will work just fine. This will redirect you to an empty website with the following in the URL bar
    • http://localhost/?code=[CODE] where the [CODE] is the part we want to copy
    • One thing to note is that it is typically required that the URL you use as redirect_uri is added on your developer site (i.e. -> My applications -> Settings -> Add URI)

Once the URL is put together with the information above, you simply enter it in the address bar of your browser and follow the steps 🙂

3. Exchange code for access token

At this point we’re almost at the end we just need to exchange the code for the actual access token.

This is done be sending what’s called a POST which is just a way of interacting with the web same as the request we previously made against which could be described as something called a GET.

I encourage you to not be too frightened by terminology such as POST and GET. It is essentially just ways of interacting with the web and in Alteryx the difference is simply determined by what you put in the payload tab in the download tool.

This POST should be pointed at and accompanied be a couple of parameters.
Here the parameters are either of the Header or body type.

New terminology but nothing more confusing than just knowing that the headers should be added in the headers tab of the download tool and the body type should be added to the payload tab of the download tool.

For this part we are required three body parameters and one header

  1. Body parameters
    • grant_type – This should be set to authorization_code
    • code – This is what we just received from step 2.
    • redirect_uri – This should be set to the same URL that was used in step two (i.e. http://localhost)
  2. Headers
    • Authorization – This should be set to “Authorization: [base64 encoded client_id:client_secret]
      • Above the client id and client secret are added together [client_id]:[client_secret] and then base 64 encoded which can be done with an Alteryx tool.
      • The client id and secret can be found under My applications on the developer site.

When sending this POST you will receive an access token and a refresh token.
This is exactly where we want to be.

The access token is what we need to pull data through the API

A simple recap of how to do the above in Alteryx

The workflow to retrieve the the access token is as simple as below:

From the various information gathered from step 1 and 2 construct the following dataset in a textinput in Alteryx.

Now we need to create the “Authorization” Header as a combination of the client_id and client_secret fields. So we add a formula tool.

Authorization = 

Now we Base 64 encode the string with the Base 64 encoder tool.
This new encoded string needs some final modifications before it is ready – Therefore we add another formula tool.

We connect a download tool and configure the taps as follows:

  • Basic
    • The url field is set to POST from the dataset we just created
  • Headers
    • Set a check mark for Authorization
  • Payload
    • Set the HTTP action to POST
    • Set a check mark for grant_type
    • Set a check mark for code
    • Set a check mark for redirect_uri

The download tool adds two fields to our dataset DownloadData and DownloadHeaders where the only field we’re interested in is the DownloadData field, therefore we add a Select tool and remove redundant fields.

Next we use the JSON parser to extract the received data and we have the access token.

4. Keeping the token alive

The access token we retrieved from step 3 is valid, in the Spotify case, for one hour.
To keep our access alive we have to use the second part of what we received from step 3 – The refresh_token.

Exactly as in step 3 we need to send a POST, but this time we have to send it with slightly different parameters.

Again we POST against

This time we have 3 parameters:

  • Body parameters (Added in the payload tap in Alteryx)
    • grant_type – Should be set “refresh_token”
    • refresh_token – Should be the refresh token received in step 3
  • Header parameters
    • Authorization – Exactly as in step 3

The above will return a new and fresh access token every time it is called.