Using the Spotify Web API in Framer Classic

Prototyping is an essential part of validating ideas. The ability to user test ideas, without having to fully implement them, makes a world of difference as does the opportunity to demonstrate a concept to your colleagues. What makes Framer stand out, to me, among other prototyping tools is the fact you can do anything in it — from simple interactions to complex prototypes.

Framer, under the hood, is basically a specialised web page, meaning any web technology out there can be used in Framer as well.
At Spotify this means we can use our Web API to populate prototypes with real data.

Understanding Authentication

Most Web APIs these days require authentication at some level and the standard way of authenticating is called OAuth. For example, in the Album endpoints, those marked with OAuth in the last column require authentication.

The basic OAuth flow I’m talking about here assumes the developer has a server hosting a website, which is being accessed by a user. The user is briefly sent to another website (Facebook, Google, Spotify, etc.) to login and grant access on behalf of the developer’s server, and then sent back to that developer’s website.

This is a simplified version of what happens when a website requests information from Spotify which in turn requires authentication.
My web browser requests something from CoolMusicWebsite, which then asks Spotify for permission. Spotify then asks me if I want to give them permission and I can choose to do that or not.

In order for this process to work, the Spotify Web API needs to know how to identify CoolMusicWebsite and which address at CoolMusicWebsite should it send the user back to. These two elements are known as the Client ID and the Redirect URI.

Using OAuth in Framer

The thing with Framer is that it is both a browser and a server, just you might not realise it. OAuth wouldn’t work with just an html page on your machine, so Framer’s dual nature is crucial. Both the device view in Framer Studio and downloaded prototypes running in Framer for iOS are in fact powered by a locally running server.

Try putting the following into a Framer project:

and you’ll see something like:

Notice that the host is 127.0.0.1. This is a special address which means ‘loopback’; in other words that this device is the server.

Now we know what our Redirect URI for OAuth should be, it’s the full href string to our project:

Now we can add our project to the Spotify Web API Applications Console by creating an application:

Once the application has been created, you can fill out the required details.
The description and application name are not really important because we’re not planning on releasing this publicly, but they will be shown to any user logging in to your prototype.

The important fields are Client ID and Redirect URIs.
We’ll come back to the Client ID, but now you can see where it is:

Copy and paste the href that Framer printed into the Redirect URIs field and press ADD.
That’s this one in our example project:

Remember to click the SAVE button at the bottom of the page!

Ok, now we’ve told the Spotify Web API which URI to whitelist, that is where to send users back to after authentication.

Performing Authentication

Now Framer can start authenticating against the Web API. To do this it first asks the user to grant the privileges it needs. This view is controlled by the OAuth provider (Spotify in our case), it’s a web page hosted by Spotify and Framer cannot control it. All Framer can do is ask for a certain set of privileges, pending user approval.

These privileges are called Scopes; as in the scope of control Framer can have over someone’s account. For Spotify the list of possible scopes an application can request are here.

In order to ask the user to grant the scopes, Framer sends them to

As it does so it also needs to identifiy itself to Spotify. The developer can do this by adding a couple of parameters to the request. Response Type which we want as a token, our Client ID and our Redirect URI.

If you remember, the Client ID was listed in your application page on developer.spotify.com.

A complete basic request looks like this:

Finally, if we want Framer to have the special privileges discussed earlier, they should be added to the request with Scopes. In this case we’re asking the user if we can see their email address with user-read-email:

Making The Request

So by now you might be wondering how do I actually make the request?
Well, you can also set window.location in Framer to a new address; which means load a different web page other than the prototype inside the Framer viewer.

In our prototype we’d do this:

When we make this request the user gets shown a dialog like this:

Clicking OKAY will grant us the privileges to use the Web API on the user’s behalf. Conveniently, once the user has granted this privilege, we don’t have to ask them again, even if we quit Framer or restart our prototype.

When the user grants the privilege they get redirected back to the Redirect URI we set earlier in the Developer console; i.e. back to our prototype.
This time, however, the prototype will be passed an Access Token — a special code that we can use to authorize the requests we make to the Web API.

Now, if we look at the output from the location object:

We’ll see the access token appended to the prototype url:

A Problem

At this point you might have realised we have a problem. If our prototype is setting the Framer view to a different website (Spotify’s Authorization Endpoint), then that means our prototype is no longer loaded. This means that none of the variables in our prototype are available and we can’t even run any code.

As the Spotify Web API redirects our user back to the prototype, the prototype will start from scratch — attempting to authenticate again.
We’ll end up stuck in an infinte loop of trying to authenticate against the Web API and being redirected back to the prototype.

So, we need to check whether Framer has already authenticated.
Luckily, that’s easy because the Redirect URI will have the access token appended.

So:

In this case Framer authenticates once and won’t attempt to authenticate again if an access token is present.

The Access Token

Now that there is an access token we can extract it out of the Location object. A simple bit of string parsing to extract the access token from the whole hash works nicely:

Great, so Framer has used the Client ID and Redirect URI to authenticate and get an access token for our prototype. Now what?

Using the Web API

Now we have an access token, we can stay within our prototype in Framer and make the requests necessary to populate our design.

This is a simple example where we ask the https://api.spotify.com/v1/me endpoint for the current user’s information and we get back a JSON object.

We use our access token in the Authorization request header:

and we also set the response type to ‘json’ to make things easier in Framer:

Here’s the complete call and handler to receive the response:

and here’s the response we’ll get back:

We can use this, for example, to put the user’s profile image and name into a prototype:

And we get this in the Framer preview:

Pretty neat!

Some Things To Be Aware Of

1. Token Expiration

Another part of the Redirect URI is the expires_in value. This is the number of remaining seconds that the access token is valid for. Generally access tokens are valid for an hour. After this, your Framer prototype will have to authenticate again to carry on using the Web API.

As the user has already granted privileges to the Framer prototype, they won’t be prompted again, but the redirect flow will still need to take place so that Framer can retrieve a new access token. This means that your Framer prototype needs to reload the authorisation page using the same technique:

As a result, your prototype will have to be unloaded and reloaded each time you have to get a new access token, i.e. every hour.
This means you will lose any state you have in your prototype
to perform re-authentication.

2. Security implications

It’s common in the Framer community to share prototypes with other developers, which is a great way to learn. But you should be aware that anyone who can see your Redirect URI and Client ID can also use it in their own application.

Because 127.0.0.1 is a standard address anyone can use it; you don’t control access to the host because it can be any host. This means anyone can spoof your Redirect URI from their own machine and pretend that they are running your application. If a user has granted privileges to you, they have granted those same privileges to that spoof application. This could be used to do malicious things to the user’s account for which you would be accountable as it is your Client ID.

The solution to this is to keep in mind that prototypes are temporary:

Remove Redirect URIs from developer.spotify.com once you have finished with them.

Delete your application from developer.spotify.com so that the Client ID becomes invalid.

It’s free and easy to create a new application with a new Client ID whenever you need to, so don’t leave ‘stale’ applications active when your Client ID is publicly available.

What’s Next?

As OAuth is a standard, the same techniques can be applied to Facebook’s APIs or Google’s APIs.

Happy prototyping!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store