What Changed in the Spotify API in 2026 (and How to Adapt Your Python Code)

Q: Why does Spotify reject my localhost redirect URI?

Spotify no longer accepts localhost as a redirect URI. Use the loopback IP instead and register it exactly as http://127.0.0.1:8888/callback. A localhost value will cause the authorisation step to fail with a redirect-uri mismatch.

By Simon O'Connor · 18 June 2026 · 7 min read PythonSpotifyAPI

You followed a Spotify-in-Python tutorial, copied the code carefully, and it still does not work. The dashboard will not let you create an app, or the authorisation step throws a redirect error, or a method that used to return data now fails. You are not doing it wrong. The rules changed in 2026, and a lot of older tutorials have not caught up.

This post is a quick map of what actually changed and how to adapt your Python code, so you can tell a real bug from a policy shift you simply had not heard about. We will cover four things: the new Spotify Premium requirement for registering a developer app, the tighter limits on development-mode apps, the switch from localhost to 127.0.0.1 for redirect URIs, and the deprecation of the audio-features endpoint.

If you want a full hands-on walkthrough rather than a changelog, see Build a Spotify Music Time Machine with Python and OAuth 2.0, which builds a working integration end to end with these changes already baked in.

You now need Spotify Premium to register a developer app

This is the change that stops most people before they write a line of code. Since February 2026, the Spotify account that registers a developer app must hold an active Spotify Premium subscription. A free account can no longer create a developer app.

The distinction matters: a free account can still stream music perfectly well, and your app's eventual users do not all need Premium. What changed is the registration step. The account that owns the app, the one you log into the developer dashboard with, is the one that needs the subscription.

How to adapt: make sure the account you use to create the app on the developer dashboard is on Premium. If you have been trying to register with a free account and the dashboard refuses, that is the reason. Switch to a Premium account (or upgrade the one you have) and the registration flow opens up again.

Development mode got stricter

Once you can create an app, the second surprise is how constrained a fresh app is. A development-mode app now has tighter limits than older tutorials assume. It can grant access to at most five test users, and you are limited to one app per developer account. Reaching a wider audience means applying for extended quota, which Spotify now reserves for registered businesses.

Whether this is a problem depends entirely on what you are building. For a personal project, a portfolio piece, or anything where you and a handful of friends are the only users, five test slots and a single app are plenty. You can build, demo, and ship a real integration without ever leaving development mode.

It becomes a barrier the moment you want a public product that strangers can sign into. That path now runs through the extended-quota application, and that route is built for registered businesses. If your goal is a hobby tool or a learning project, none of this slows you down. If your goal is a launched product with open sign-ups, plan for the business-facing process rather than expecting development mode to scale with you.

localhost is out, 127.0.0.1 is in

Here is the one that produces the most confused bug reports. The redirect URI you register must use the loopback IP 127.0.0.1, not localhost. Spotify no longer accepts localhost as a redirect URI, so the two are no longer interchangeable.

This trips people because localhost and 127.0.0.1 resolve to the same machine, and for years either one worked. Older tutorials still show http://localhost:8888/callback, you copy it faithfully, and the authorisation step fails. The fix is a one-character-class change: register the loopback IP instead.

A localhost redirect URI fails the authorisation step

If you register http://localhost:8888/callback and then run the OAuth flow, the authorisation step fails with a redirect-uri mismatch rather than a clear "localhost is not allowed" message. The signature is an auth error that points at the redirect even though the value looks correct. Swap localhost for 127.0.0.1 in both the dashboard and your local config, and make sure the two match exactly.

The rule behind this is an ordinary OAuth one: the redirect URI you send during the OAuth 2.0 authorization code flow must be an exact, character-for-character match for one you registered on the dashboard. Scheme, host, port, and path all have to line up. Because Spotify dropped localhost from the allowed hosts, the only thing that satisfies the match now is the explicit IP. In your project config that looks like this:

.env

SPOTIPY_REDIRECT_URI=http://127.0.0.1:8888/callback

Audio features are gone

The fourth change affects what your code can ask for. Spotify deprecated the audio-features endpoint. If you followed a tutorial that ranked tracks by danceability, energy, or tempo, or that sorted a playlist by the audio-analysis family of values, that data source is no longer available to build on.

Plenty of older project ideas leaned on those numbers, so this one quietly breaks a whole category of tutorials. The good news is that the endpoints that remain still support genuinely useful projects: your top tracks across different time ranges, your playlists, and your listening history are all still there.

How to adapt: build with what remains rather than around what is gone. A "rediscover forgotten favourites" tool, a monthly snapshot of your top tracks, or an analysis of how your listening shifts over time all work entirely on top tracks, playlists, and history. The Music Time Machine tutorial linked above is built on exactly those endpoints, so it is a good model for an audio-features-free project.

How to keep your project working

Pulling the four changes into a short checklist, here is what to verify before you blame your own code:

Owning account on Premium. The account that registers the app on the developer dashboard needs an active Spotify Premium subscription.
Redirect URI uses 127.0.0.1. Register and configure http://127.0.0.1:8888/callback, not the localhost form, and make the dashboard value and your local config match exactly.
Do not depend on audio features. Build on the endpoints that remain, such as top tracks, playlists, and listening history.
Check the official source for current terms. Quotas, limits, and endpoint availability move over time. The Spotify developer dashboard and changelog are the authoritative source for what is true today.

APIs are moving targets, so build for change

Every one of these shifts would have been a smaller problem in a project that expected change. If you isolate the Spotify calls behind a thin client, validate responses instead of assuming a field is always present, and avoid hard-wiring one endpoint into the core of your app, then a deprecated endpoint or a tightened quota is a contained edit rather than a rewrite. The specifics here are about Spotify, but the habit applies to every third-party API you integrate.

Frequently asked questions

Do I need Spotify Premium to use the API in 2026?

Yes, to register a developer app. Since February 2026, the Spotify account that creates a developer app must hold an active Spotify Premium subscription. A free account can still stream music, but it can no longer create the developer app your integration depends on.

Why does Spotify reject my localhost redirect URI?

Spotify no longer accepts localhost as a redirect URI. Use the loopback IP instead and register it exactly as http://127.0.0.1:8888/callback. A localhost value will cause the authorisation step to fail with a redirect-uri mismatch.

Are Spotify audio features still available?

No. Spotify deprecated the audio-features endpoint, so projects now work with the endpoints that remain, such as top tracks, playlists, and listening history. You do not need audio features to build a useful Spotify project.

Build Spotify integrations that survive API changes

This post covers the what-changed; the book covers the how-to-build-it-well. Mastering APIs With Python builds a real Spotify project end to end (OAuth authentication, a SQLite database, error handling with retries, and automated tests) on top of the endpoints that remain, then takes you all the way to deploying production systems on AWS. Thirty chapters for €35. You can browse the full curriculum to see how OAuth, databases, and deployment fit together.

Get Full Access