Spotipy: the Spotify Web API, one import away

All endpoints, one client object

Spotipy is a lightweight Python library for the Spotify Web API, and its feature claim is total, support for all of the features of the API including access to all endpoints and user authorization, with the README directing readers to Spotify's own documentation for the capability list rather than maintaining a duplicate. The design consequence is visible in the quick start, one client object constructed with an auth manager, and then namespaced methods standing in for the API's endpoints, so the library's learning curve is the API's learning curve plus one constructor. The package is MIT licensed, its documentation lives on Read the Docs, and there is a Discord server for the community, the standard furniture of a library that knows its role, a thin, complete, stable wrapper rather than an opinionated framework around someone else's service.

pip install, then two lines to music data

Installation is a single line, pip install spotipy, with the Windows variant py -m pip install spotipy documented alongside and an --upgrade form for updating. The setup before code is Spotify-side, create an account or log in at developers.spotify.com, open the dashboard, create an app, and put the resulting ID and SECRET into your environment. Without user authentication, app-only access to catalog data needs just the credentials auth manager:

import spotipy
from spotipy.oauth2 import SpotifyClientCredentials

sp = spotipy.Spotify(auth_manager=SpotifyClientCredentials(client_id="YOUR_APP_CLIENT_ID",
                                                           client_secret="YOUR_APP_CLIENT_SECRET"))

results = sp.search(q='weezer', limit=20)
for idx, track in enumerate(results['tracks']['items']):
    print(idx, track['name'])

The README shows the expected result, twenty Weezer track names, a complete working example in ten lines that touches search, pagination-shaped response handling and dictionary access, the pattern every Spotipy script follows.

User authentication needs a redirect and a scope

The second quick start covers the user-authenticated half of the API, and the README flags the prerequisite, a redirect URI must be added to the application in the dashboard before any user-authenticated feature works. The code swaps the credentials manager for SpotifyOAuth, passing the client pair plus the redirect URI and a scope string, user-library-read in the example:

import spotipy
from spotipy.oauth2 import SpotifyOAuth

sp = spotipy.Spotify(auth_manager=SpotifyOAuth(client_id="YOUR_APP_CLIENT_ID",
                                               client_secret="YOUR_APP_CLIENT_SECRET",
                                               redirect_uri="YOUR_APP_REDIRECT_URI",
                                               scope="user-library-read"))

results = sp.current_user_saved_tracks()
for idx, item in enumerate(results['items']):
    track = item['track']
    print(idx, track['artists'][0]['name'], " - ", track['name'])

The scope mechanism is Spotify's own, the library enumerating exactly what the app may read, and the auth manager handles the token exchange and refresh, the part of OAuth that rewards using a library instead of an HTTP client.

Redis in the base install, memcache as an extra

The dependency list in setup.py tells an architectural story. The base install requires redis, requests and urllib3, with a code comment marking the Redis dependency for movement to extras in a future version 3, meaning token caching currently ships through Redis by default and is baked into every install. A memcache extra adds pymemcache for deployments preferring that cache, revealing the cache-handler pattern underneath, auth tokens are expensive to re-acquire and the library persists them rather than refreshing per run. Python requires greater than 3.8, and the test extra carries the formatting and linting stack, autopep8, flake8 with a use-fstring plugin enforcing modern string formatting, and isort. It is a deliberately small footprint for a client library, three runtime dependencies and an escape hatch, with the caching being the one opinionated inclusion.

Support routed by question type

The support section sorts inquiries before they arrive. Common questions are answered in a committed FAQ file, the first stop. Usage questions belong on Stack Overflow with the Spotipy tag added before posting, keeping the community's searchable knowledge where search engines already look. Suggestions, bugs and library-specific issues go to the GitHub issue tracker, and pull requests are welcomed outright, or just send a pull request, as the README puts it. Contribution guidelines live on the documentation site with a stated audience, developers with Python experience, and a code of conduct backs the community. The routing discipline matters more than it appears, an API wrapper's issue tracker fills instantly with Spotify-side and OAuth questions otherwise, and this one defends its maintainer attention by design.

A changelog that names its CVEs

The release history is unusually security-literate. Version 2.25.1 is titled with CVE-2025-27154 and 2.25.2 with CVE-2025-66040, patch releases named directly for the vulnerabilities they fix, so an operator scanning the changelog can match the library against advisories without cross-referencing commit logs. The current release, 2.26.0 from March 2026, is titled Deprecated methods, flagging surface removal that migrating code needs to know about, and the repository's last push came on 2026-06-29. The project originated under Paul Lamere, the author on the package metadata, and now lives under the spotipy-dev organization with the examples split into a dedicated spotipy-examples repository, the library and its demonstrations maintained as siblings rather than one tree.

Longevity as the pitch

Measured against its alternatives, Spotipy's advantage is not a feature matrix but incumbency and completeness, every endpoint the Web API exposes, an auth layer covering both app and user authorization, a caching story, and a decade-plus history including prompt security maintenance, wrapped in a package that stays lightweight. The TUTORIAL.md and the examples repository extend the quick start's two examples into the fuller surface, the FAQ absorbs the recurring confusion of OAuth newcomers, and the Read the Docs site holds the reference. For a script that archives a playlist, a service that analyzes listening history or a bot that queues tracks, the decision is simply this library, and the moments it disappoints are the moments the upstream API itself changed, which is the correct failure mode for a wrapper to have.

Editorial conclusion

Use Spotipy whenever Python code needs Spotify data, search, catalog metadata or a user's library, since it wraps every Web API endpoint behind one client object and handles the OAuth flows that make raw integration tedious. Use the Web API directly only when the dependency budget cannot fit the small requests-based client. Verify first that your developer dashboard app exists with its client ID and secret in the environment, add a redirect URI before any user-authenticated scope, and read the FAQ and the deprecated-methods changelog entry when upgrading, since 2.26.0 retired older surface.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. spotipy-dev/spotipy on GitHub