September 26th, 2016 by José M. Pérez
Part of maintaining a large scale API is ensuring we are able to properly monitor how our product is consumed both globally, and on a per-app basis. Over time this information has proven invaluable when working with partners to optimise their experiences, and we’ve spent some time creating internal tooling to visualise that data for fast and easy insights.
We have just launched a new feature in the “My Applications” section of the Developer Site giving everyone those same insights into how your application is consuming the Spotify Web API, how engaged your users are, and where in the world they are located.
To view your insights, navigate to your app in the My Applications” section and click on the new “Statistics” section. We look forward to your feedback – tweet us at @SpotifyPlatform.
July 25th, 2016 by Andy Smith
We will soon be releasing the ability for users to revoke account access for applications for which they have previously granted access. If you have written an app which uses the OAuth “Authorization Code” or “Implicit Grant” flows, you should make sure that you app is ready.
How this will affect your app
From August 9th, Spotify users will be able to visit https://www.spotify.com/account/ to revoke access for applications they have previously granted access.
If your application uses the “Authorization Code” or “Implicit Grant” flow, the user will be presented with your application’s name and description, along with a link to revoke access.
If the user chooses to revoke access, any Authorization Code refresh_token you store on behalf of that user will be made invalid and you will be unable to use them to request additional access_tokens. If you use Implicit Grant, the scopes that the user previously allowed will be cleared and the user will be prompted to re-allow next time they use your application.
If a request is made to
https://accounts.spotify.com/api/token with a revoked or expired refresh_token, your app will receive a
400 Bad Request response with the following payload:
HTTP/1.1 400 Bad Request
In order to continue using your application, the user will need to explicitly grant access by going through the Authorization Code flow again, as they did the first time they used your application.
What you should do
Ahead of this update, there are a few things you can do to ensure a good experience for your users:
- Update your application’s name and description
The list of applications available for revocation will display your application’s name and description as specified in the developer portal’s “My Apps” section. Ensure that these represent an up-to-date, informative, and concise explanation of what your application does so that the user does not revoke your access simply because they did not recognise it.
- If you use Authorization Code flow, ensure your application can cope with an invalidated refresh_token.
If the user instigates an action which requires a new access token, and access has been revoked, you should detect the denied refresh request (detailed above) and push the user into the initial oAuth flow.
If your requests are automated and you receive an HTTP 400 error, you should halt automatic token refresh until the user has re-allowed access for your application.
- When access is revoked, clean up any cached information for that user.
It is good practice to clean up any artifacts left over from a user who has finished interacting with your service or application. This can include any user-specific data you have cached along with any refresh_tokens or user-specific information within your app.
June 21st, 2016 by Andy Smith
On Wednesday 29th June we will release an update for all client IDs to enable your application to read which scopes have been granted by the user when requesting or refreshing access tokens.
After the change, any calls made to
https://accounts.spotify.com/api/token in order to request or refresh tokens on behalf of a user will additionally return a space-separated list of the scopes granted in that token.
Response as of 29th June 2016:
"scope": "scope1 scope2 scope3",
This change allows your application to know whether you need to ask an individual user to re-authenticate with new scopes after you have added new functionality into your implementation, or whether the token you are refreshing already contains permission for all the necessary scopes.
In most cases, you should not need to take any action in preparation for this change, unless your implementation cannot cope with additional information being provided.
March 29th, 2016 by Petter Skidén
We’re always working to make improvements to our Web APIs and today, we have some updates to share that will impact both The Spotify and The Echo Nest Web APIs.
Over the past two years, following Spotify’s acquisition of The Echo Nest, it’s become clear that rather than have two separate APIs with considerable overlap in features, it makes sense to migrate functionality and focus all of our future development on the Spotify API.
In doing so, there are a couple important dates you should be aware of:
- March 29th, 2016 – We are announcing three new APIs (details below) and The Echo Nest API will no longer be issuing new API keys
- May 31, 2016 – The Echo Nest platform will no longer serve requests and developers will need to move over to the Spotify API.
As part of our migration of many of The Echo Nest API features over to the Spotify Web API, we’re announcing three new APIs today. The new Spotify Web APIs include:
- Audio Features – Access to audio information about tracks (energy, danceability, tempo, loudness, etc. as well as full detailed audio analysis)
- Recommendations – A recommendation API (to generate a list of tracks given a starting point from a seed artist, track or genre), with filtering capabilities to restrict the set of tracks that are returned.
- User’s Top Artists, Tracks – Top-level user information such as top artists and tracks.
If you currently have an app that uses The Echo Nest API, check out the Spotify Web API as we’ve already migrated the most-used features.
As always, we’ll continue to add additional features and enhancements to ensure you have what you need for development.
For more information on these new APIs check out this post.
March 29th, 2016 by Petter Skidén
Over the two years since Spotify acquired The Echo Nest, we have folded much of the power of The Echo Nest into Spotify’s stack. With today’s announcement of the wind down of The Echo Nest API, we’re happy to launch three new endpoints to bring some of the best parts of The Echo Nest’s API to Spotify.
Spotify runs a suite of audio analysis algorithms on every track in our catalog. These extract about a dozen high-level acoustic attributes from the audio. Some of these are well-known musical features, like tempo and key. Others are more specialized, like speechiness or danceability. Our new Audio Features API makes all of this analysis available for every track in Spotify’s catalog.
You can see this API in action through Paul Lamere’s Sort Your Music and read more details about this API in the endpoint docs.
Our first recommendations API generates listening experiences based on a set of seed artists, tracks, genres, or a combination of all three. If you would like to tweak your results further, you can filter on audio features and track popularity to easily build a great set of tracks for your application.
Our friends at Hydric Media have made a recommendations explorer you might be interested in checking out in addition to the full docs.
User Top Artists and Tracks
We are introducing a new API endpoint that will allow developers to retrieve the top artists and tracks for a Spotify user once the user has granted access. This API will make it easier for developers to create personalized experiences for their users.
This data is calculated based on the listening and other behavior of users and we’re computing it over three different time ranges. The short-term dataset represents only the most recent actions of a user. The medium-term dataset reflects a broader, slower changing sense of their listening preferences. The long-term dataset incorporates the user’s entire listening history.
Take a look at the docs.
These endpoints are all ready for experimentation in the web console. For a complete list of currently available endpoints, see our Web API Endpoint Reference.
March 22nd, 2016 by manager
As some of you may already know, Spotify’s C library Libspotify recently experienced some major issues. The purpose of this blog post is to give you a brief overview of what went wrong and what we’re doing to prevent it from happening again.
It’s important to add that Libspotify isn’t under active development on any platform and is considered deprecated. If you’re building applications for iOS or Android, we strongly recommend that you use the iOS SDK or Android SDK instead.
To give some background on our infrastructure, Spotify’s backend is built on a microservice architecture with teams developing and maintaining services necessary to deliver on their missions. More often than not a service built by one team is used by a whole bunch of other teams. While this helps different parts of Spotify to work more autonomously, it also requires the teams to make sure that services in a dependency-chain don’t suddenly change their API or be taken down or changed without notice, very similarly to how third-party developers and partners rely on Spotify to keep their externally accessible APIs and SDKs working – Spotify can’t make breaking changes or take down an API without prior notice.
Applications using Libspotify are making requests to several different services within Spotify, and during a period between January 21st and February 22nd two of them were either mistakenly taken out of production or failed to restart properly after patching the libc vulnerability, causing Libspotify based applications to stop working properly.
The incidents happened close in time to the planned end-of-life for the Metadata API, Spotify’s old Web API, causing people both internally at Spotify as well as externally to believe that the Metadata API take-down was the cause for Libspotify’s degradation of service. The Metadata API, which is not used by Libspotify, was turned off on January 18th, a few days prior to the Libspotify issues began.
The services used by Libspotify that had stopped working, those returning toplist and search data, were online and working again as of February 22nd. The service owners have revisited their logging and alerting, making sure that they’ll be notified whenever one of their services isn’t starting up or otherwise working as intended. To prevent and clear up any confusion around this topic we’ve begun building a closer relationship between Spotify Platform team and @SpotifyCares in order to provide clearer response to developers when we run into technical issues that might affect our developer tools. We’ve also revisited who has access to the @SpotifyPlatform account to make sure that we can quickly respond in case incidents occur again in the future.
Lastly, we sincerely apologize for any inconvenience that this outage have caused.
The Spotify Platform Team
July 27th, 2015 by Andy Smith
We’re pleased to announce that Spotify now has a channel on IFTTT, the platform that allows users to control and connect a wide variety of connected products and apps.
The Spotify Channel enables you to easily link Spotify’s API functionality to a wide range of platforms and products like Twitter and Facebook, as well as smart products like the Philips Hue light bulb, with connections known as “recipes”.
With this integration, users can create recipes such as:
- Automatically send a tweet when you save a Spotify track to your favorite playlist
- Automatically follow songs on Genius that you’ve added to your library
- Save your favorited songs from Last.FM to your library
The Spotify Channel on IFTTT supports the following triggers and actions:
- New Saved Track (Trigger) – This fires whenever you save a track to Your Music on Spotify
- New Track Added to a Playlist (Trigger) – This fires every time a new track is added to a playlist that you specify
- Save a Track (Action) – This will search for a track that you specify and save it automatically to Your Music on Spotify
- Add Track to a Playlist (Action) – This will search for a track and add automatically add it to a playlist that you specify
To get started on creating your own recipe, visit the Spotify Channel on IFTTT here: https://ifttt.com/spotify
May 26th, 2015 by José M. Pérez
Time for some news on what we have been working on recently!
Collaborative Playlists Now Supported in Our Web API
Many of you have requested that collaborative playlists should be supported in the Spotify Web API. Our developers have worked hard on making this happen and we recently released a new scope; playlist-read-collaborative. With this, you can:
Read your collaborative playlists
- Add tracks to collaborative playlists that you own
- Reorder and remove tracks in collaborative playlists that you own
- Change the details of collaborative playlists that you own
You can try this out yourself, using our Web API Console. Find out more on Using Scopes and Collaborative Playlists.
February 27th, 2015 by Chris Hughes
In the past month we’ve been making further improvements to our Web API and our mobile SDKs. We have a new guide covering authorization options for the Android SDK, three new Web API endpoints, a modification that allows tracks to be linked to alternatives according to the users market, and several other updates. Let’s take a look… (more…)
February 4th, 2015 by Jonathan Marmor
Recently we attended a massive hackathon at the University of Pennsylvania from January 16-18, where high-level student technology creators from around the globe made some amazing things using APIs including those of Spotify and subsidiary The Echo Nest. (more…)