Another wrapper for the Spotify Web API, built on top of requests
and
requests_oauthlib
.
I wrote this package as a kind of "code generation experiment": the code (and doc) of
Spotify
class was almost entirely generated using a script that scrapes the
official Spotify Web API documentation.
For scripts and desktop apps, this package (optionally) includes a flask server (meant to be run locally) to handle user authorization without requiring the user to manually copy and paste the OAuth2 callback URL (containing the token) from the browser to your app.
- Free software: MIT license
If you don't need the authorization flask app:
pip install spotipie
otherwise:
pip install spotipie[auth-app]
Obtain your credentials as described here.
(Optional) Store your credentials and redirection URI as environment variables:
SPOTIPIE_CLIENT_ID
SPOTIPIE_CLIENT_SECRET
SPOTIPIE_REDIRECT_URI
;
you could also use another prefix,
SPOTIPIE
is just the default one.To use the
spotipie.Spotify
client you first need to create an HTTP session and authenticate it. TheSpotify
constructor takes whatever behaves like arequests.Session
.spotipie
provides one session class for each of the three OAuth2 authorization flows supported by the Spotify API (see Authorization Flows); these classes are built on top ofrequests_oauthlib.OAuth2Session
(by composition, not inheritance):ClientCredentialsSession
AuthorizationCodeSession
ImplicitGrantSession
To see how to create a session, see the Examples.
Once you have an authenticated session, you can wrap it with the client and you're ready to make any API call you want:
spotify = Spotify(session) results = spotify.search('symphony', obj_type='playlist')
See the API of the client here.
A backend web application should use:
- the client credentials flow if it doesn't need access to private user data;
- the authorization code flow otherwise.
For scripts and desktop application... it's more complicated. The recommended flow in this case is "Authorization code with PKCE" but it's not supported by Spotify at the time I'm writing this.
It's not recommended to distribute your code with your API secret key in it, so both the client credentials flow and the authorization code flow should not be used, unless you ask your users to use their own API keys; this can be acceptable if your target users are other developers.
The implicit grant flow was designed for apps that run in the browser but has been used for "native apps" too since it doesn't need the client secret key; unfortunately, for native apps, it's neither very safe nor convenient from a user perspective since the authorization is not refreshable.
All the examples assume your API credentials and redirect URI are stored as environment variables.
- Client credentials flow
- Authorization code flow for scripts / desktop apps
- Implicit grant flow for scripts / desktop apps
- Flask web app (authorization code flow)