Spotify Audio Features Is Dead. Here's What to Use Instead in 2026.

On November 27, 2024, Spotify deprecated audio_features, audio_analysis, recommendations, related artists, and featured playlists in one quiet developer-blog post. New apps got 403s the same day. Eighteen months later, there is still no official replacement — and the February 2026 changes made the rest of the Web API harder to use, not easier.

If you built anything that depended on BPM, key, danceability, energy, valence, or any of the other 11 numbers Spotify used to hand out for free, you've already had to replace it or you're maintaining a fork that exists only because of one grandfathered token.

This post is the honest version of "what now?" — what each of the realistic replacements actually gives you, where they fall short, and a copy-paste migration example.

What actually died, in one table

Apps that had a quota extension in flight on November 27, 2024 are still live. Everyone else gets 403. There is no path to access these endpoints for a new app, no waitlist, and no public statement that this will change.

Why Spotify isn't bringing it back

The honest read is that Spotify never wanted to host this data in the first place. The audio_features endpoint is a thin wrapper around analysis Spotify acquired when they bought The Echo Nest in 2014, plus features derived from the AcousticBrainz dataset (which itself shut down in 2022 because of similar "we don't want to host this anymore" reasoning). Returning eleven floats for every track in a 100-million-track catalog costs Spotify infrastructure for zero strategic value — nobody's paying premium for "give me the BPM of Blinding Lights."

Worse for developers: the recommendations endpoint was a competitive liability. Letting any third party build a Spotify-quality recommender by spamming seed_genres=house&target_energy=0.8 queries undermined the whole "premium algorithm" pitch. Killing it makes commercial sense for Spotify even though it leaves thousands of apps broken.

The realistic options in May 2026

Five categories of replacement, ranked by how quickly you can ship the migration:

1. Apple Music API

Apple exposes tempo, key, timeSignature, contentRating and a few mood/genre tags via MusicKit and the catalog API. Free for developer accounts, requires a paid Apple Developer subscription to ship to production ($99/year). What it doesn't have: danceability, energy, valence, acousticness, instrumentalness, liveness — six of the eleven Spotify fields, gone. Good for "I just need BPM and key from a major catalog and I'm OK paying Apple."

2. Build your own with Essentia

Essentia is the open-source MIR toolkit Spotify itself used to derive most of the deprecated values. MusicExtractor takes a 30-second audio clip and returns BPM, key, danceability, average loudness, dynamic complexity, tuning frequency, onset rate — basically the Spotify schema with a few extras. Run it on a VPS with a worker queue and you've got your own replacement at compute cost only. Catch: you need the audio. Spotify never let you download it; iTunes 30-second previews are usable but rate-limited to ~25 RPM in our experience. Plan for a multi-week backfill on any catalog over 10k tracks.

3. AcousticBrainz public dump (free, frozen)

The MusicBrainz folk did exactly what Spotify won't: published the entire AcousticBrainz dataset (7.5M tracks, 11 high-level features and ~120 low-level descriptors per track) as a one-time public dump in July 2022 before shutting the service down. Catch: the dataset is frozen at July 2022 — nothing released after that has values. Coverage on tracks with a MusicBrainz ID is good (~60% of recent commercial releases); without an MBID you get nothing. Useful as a baseline layer when combined with one of the other options.

4. Musicae API

Built specifically as a Spotify shim: same field names, same value ranges, similar ergonomics. Closest drop-in if minimising migration diff matters more than anything else. Pricing is per-call and competitive. Not affiliated with us; their pitch is "we look like Spotify so your code barely changes."

5. FreqBlog Music API (us)

Different design choice: we're a catalog first, not a wrap-an-id-and-look-it-up service. You can pass a track-name + artist string and get back BPM, key, Camelot, energy, loudness, danceability, valence, mood, time signature, ISRC, MBID, and genre — from £0.17 per 1,000 requests, free tier with no card. We backfill missing tracks via a queue (returns 202 Accepted; subsequent calls return the data). What we don't match is Spotify's proprietary ML: per-segment analysis with timestamps, and Spotify-grade quality on speechiness, instrumentalness and liveness. We do return those fields (plus acousticness) for drop-in shape compatibility — as approximate single-signal heuristics, not trained classifiers (see the field guide). More on what's actually in the catalog →

Migration walkthrough: Spotify → FreqBlog

Most apps that depended on audio_features were doing one of two things:

1. Look up known tracks — user pastes a Spotify URL, app shows BPM/key/energy
2. Filter by feature ranges — "give me upbeat tracks above 120 BPM in a major key"

Here's what each pattern looked like before and after.

Pattern 1: Single-track lookup

Before:

import requests

def get_features(spotify_id, token):
    r = requests.get(
        f"https://api.spotify.com/v1/audio-features/{spotify_id}",
        headers={"Authorization": f"Bearer {token}"},
    )
    r.raise_for_status()
    return r.json()

# >>> get_features("0VjIjW4GlUZAMYd2vXMi3b", token)
# {"danceability": 0.514, "energy": 0.730, "key": 1, "tempo": 171.005, ...}

After (FreqBlog):

import requests

def get_features(spotify_id, api_key):
    r = requests.get(
        f"https://api.freqblog.com/v1/audio-features/{spotify_id}",
        headers={"X-Api-Key": api_key},   # one header. no OAuth.
    )
    r.raise_for_status()
    return r.json()

# >>> get_features("0VjIjW4GlUZAMYd2vXMi3b", api_key)
# {"danceability": 0.514, "energy": 0.91, "key": 1, "mode": 0, "tempo": 171.0,
#  "loudness": -7.1, "id": "0VjIjW4GlUZAMYd2vXMi3b", "type": "audio_features",
#  "uri": "spotify:track:0VjIjW4GlUZAMYd2vXMi3b",
#  "track_href": "https://api.spotify.com/v1/tracks/0VjIjW4GlUZAMYd2vXMi3b", ...}

When the Spotify ID is already mapped, that's the whole diff. Same path (/v1/audio-features/{id}), same response field names and shapes, same type: "audio_features" envelope — you change the host and the auth header, and your downstream code is untouched. One honest caveat: the raw-Spotify-ID drop-in only resolves tracks we've already mapped to a Spotify ID, which is a minority of the catalog today (roughly 2.4%). It is not a universal Spotify-ID reverse lookup — an unknown ID can't be turned back into a track server-side, so passing an arbitrary ID can miss even when we have the track under its name or ISRC.

For reliable results, identify the track by name or ISRC, not by a raw Spotify ID:

• Best coverage — name + artist: GET /lookup?track=<title>&artist=<artist> searches the full catalog and, on a miss, queues an on-demand fetch + analysis so even tracks we don't have yet get ingested and returned shortly.
• If you already have the ISRC (for example, your own Spotify integration already hands you external_ids.isrc): the same audio-features endpoint accepts it — GET /v1/audio-features/{isrc} — or use GET /lookup?isrc=<ISRC>. The path auto-detects 22-char Spotify IDs vs 12-char ISRCs.

Batch lookups: GET /v1/audio-features?ids=id1,id2,… up to 100 comma-separated IDs, returning {"audio_features": […]} with the same null-on-miss positional semantics Spotify used.

The numbers behave a little differently — same field names, but our values come from signal analysis (librosa + Essentia), not Spotify's ML classifiers. Before you let your downstream thresholds run unchanged, read Migrating from Spotify Audio Features: a Field-by-Field Threshold Guide — it has the catalog distribution data for each field and tells you which ones to re-tune (acousticness, liveness, and speechiness are the main offenders).

Field mapping

For the 11 Spotify fields, here's how they map to the replacement landscape:

^† FreqBlog returns these four fields from signal-analysis approximations (librosa), not Spotify-style ML classifiers — same field name, same shape, but the distributions differ. acousticness and liveness in particular have catalog medians of 0.98 and 1.0 respectively, so any Spotify threshold you imported needs adjusting. The Field-by-Field Threshold Guide has the catalog distribution numbers and recommended re-tuning per field.

Pattern 2: Feature-range filtering

If you were doing the recommendations-with-target-features dance:

# Spotify (deprecated)
GET /v1/recommendations?seed_genres=house&target_energy=0.8&min_tempo=120

# FreqBlog — direct drop-ins for the two killed endpoints
GET /recommendations?seed_tracks=<id>&limit=20   # replaces /v1/recommendations
GET /related-artists?artist=<name>&limit=20      # replaces /artists/{id}/related-artists
# …or filter the catalog by genre or tempo, or rank by similarity
GET /genres/house/tracks?limit=20
GET /bpm?bpm=120&tolerance=4&limit=20

Different endpoints, same goal. FreqBlog exposes a similarity-based recommender (/similar?track_id=...) that doesn't require seed-genre tuning — pass a track you like, get back the 10 acoustically nearest neighbours by cosine similarity over an 18-feature embedding.

What no replacement gives you

Be realistic about the gaps. None of the alternatives, including ours, replicate Spotify's old offering one-for-one:

• Per-segment analysis with timestamps. The /audio-analysis endpoint returned per-bar / per-beat / per-segment timing for a track, useful for sync apps and audio-reactive visuals. Replicating this requires you to run a beat-tracker on the audio yourself — librosa.beat.beat_track or Essentia's RhythmExtractor2013 get you most of the way.
• Spotify-grade speechiness, instrumentalness, liveness. We return these fields (plus acousticness) for drop-in shape compatibility, but as approximate single-signal heuristics — not Spotify's trained classifiers. Spotify trained its versions on internal labelled data nobody else has; the open-source Essentia models for them are flagged deprecated over data quality. Treat them as approximate (see the field guide) — for BPM, key, energy and danceability the gap to Spotify is small; for these four it's wide.
• Coverage of obscure tracks. Spotify had every track in their catalog. Every alternative has an unavoidable coverage gap on long-tail releases — especially anything outside the major-label release pipeline. Plan for a "no data yet, queue for analysis" path in your UX.

How to choose

• Already on Apple Music? Use their API, accept the field reduction.
• Need a 1:1 Spotify shim? Musicae is closest by design.
• Have audio files already? Build with Essentia, pay only compute.
• Need a catalog you can query by name+artist with BPM, key, Camelot, similarity, charts? Try us — free tier, no card.
• Building research/non-commercial work? AcousticBrainz dump is free and large enough for most academic projects.

Frequently asked questions

Is the Spotify Audio Features API still available?

No. Spotify deprecated the /audio-features and /audio-analysis endpoints on 27 November 2024. Apps that didn't already have extended access now receive 403 errors, and there's no official replacement.

What is the best Spotify Audio Features API alternative in 2026?

There's no official replacement, so the practical options are to re-derive features yourself with Essentia or librosa, or use a hosted API. FreqBlog exposes a Spotify-shaped GET /v1/audio-features/{id} drop-in returning BPM, key, energy, valence, danceability and more. For the best coverage, look up by track and artist name (GET /lookup?track=&artist=) or by ISRC; the raw-Spotify-ID drop-in resolves only tracks already mapped to a Spotify ID, a minority of the catalog.

Why did Spotify remove the audio features endpoint?

Spotify restricted audio-features, audio-analysis, recommendations and several other endpoints to existing apps as part of a broad Web API lockdown announced on 27 November 2024. It hasn't signalled any plan to restore them.

Are the audio-feature values identical to Spotify's?

No — independent APIs (FreqBlog included) derive values with open tools such as Essentia, so they're directionally compatible but not byte-identical to Spotify's. Re-tune any hard thresholds when migrating; our field-by-field threshold guide covers exactly how.

Further reading

• Full Music API Comparison 2026 — FreqBlog vs AudD, MusicAPI.com, MeloData, Cyanite, Soundcharts — side-by-side on 20+ criteria, with the per-1k pricing every other comparison buries
• Migrating from Spotify Audio Features: a Field-by-Field Threshold Guide — the companion to this post, with catalog distribution data and recommended threshold adjustments per field
• AcousticBrainz Shut Down: The 2026 Alternatives Guide — the other major open audio-features dataset that went away, and what still works
• Spotify's original deprecation announcement (Nov 27, 2024)
• Spotify Web API February 2026 migration guide
• Half-Time vs Double-Time BPM Detection: How We Fixed Spotify's Known Accuracy Gap
• Camelot Wheel for Developers: Harmonic Mixing Without the Music Theory PhD
• Why DJ Platforms Disagree on Key 60% of the Time