Model or dataset
AliAkhtari78/SpotifyScraper avatar
AliAkhtari78/SpotifyScraper

SpotifyScraper: public Spotify metadata without an API key

Extract public Spotify data — tracks, albums, artists, playlists, podcasts & lyrics — without the official API. Sync + async, typed models, one dependency.

305 stars33 forksPythonMIT

At a glance

What is it?
SpotifyScraper reads public Spotify data through the same JSON endpoints the web player uses, returning typed models with sync and async clients. It is a read-only tool, and the README is explicit about where that boundary sits.
Who is it for?
Adopt SpotifyScraper if you need public Spotify metadata, cover art or previews in Python and do not want to register an app or run an OAuth flow. Skip it if you need writes, playback control, private library data, or market-accurate availability, because the README states the client is read-only public data and that a market variable is ignored.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 12 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem SpotifyScraper solves, and who it is for

Spotify's official Web API requires an app registration, an OAuth flow, and it applies a quota. For a script that only needs a track title, a cover URL or a preview link, that setup is the bulk of the work. SpotifyScraper skips it: the README says it bootstraps an anonymous token from Spotify's own public embed pages and reads the same JSON endpoints the web player uses, with no API key and no login for public data.

The audience is narrow but real. Data engineers building a small metadata cache, bot authors who resolve a pasted Spotify link, and anyone assembling a dataset of public track or podcast metadata fit. The project also ships an MCP server for LLM hosts, which the README lists as a differentiator against the official API. It is not for account writes, playback control, or anything that touches a user's private library.

How the anonymous token bootstrap and typed models work

The data path is: request a public embed page, take the anonymous token it carries, then call the web player's JSON endpoints with that token. Every entity has its own method, and the README names them: get_track, get_album, get_artist, get_playlist, get_episode and get_show, each accepting a URL, URI, or bare ID. Responses are returned as typed, immutable models, with a to_dict() method when a plain dictionary is more convenient.

Two clients exist. SpotifyClient is synchronous and used as a context manager. AsyncSpotifyClient mirrors it and can be combined with asyncio.gather, which the README demonstrates by fetching a track and an album concurrently. The only required dependency is httpx, capped below 1.0 in pyproject.toml because the comment states httpx ships breaking changes in minor releases and upstream recommends pinning to 0.28. Everything else, including cover and preview embedding, the CLI, the keyring store and the MCP server, is an optional extra.

Localization deserves a note because it is easy to misread. A locale parameter is a BCP-47 language tag such as "de" or "ja-JP", sent as the Accept-Language header. It changes how display names are spelled and nothing else. The README states plainly that a bare "US" is meaningless as a language and is ignored, and that it does not filter regional availability or vary preview URLs, because anonymous Spotify resolves country from the request IP and its pathfinder silently ignores a market variable.

Installing SpotifyScraper and fetching your first track

The core install pulls in httpx only. Extras add cover and preview embedding via mutagen, a Playwright browser fallback, the command-line tool, OS keyring storage for the login cookie, and the MCP server. Python 3.10 or newer is required.

bash
pip install spotifyscraper
pip install "spotifyscraper[media]"

The first block is the core library. The second adds mutagen, which the README ties to cover and preview embedding. A first call creates a client in a with block and fetches a track by URL. The README's quickstart prints the track name, the first artist name, the duration in milliseconds and the preview URL.

python
from spotify_scraper import SpotifyClient

with SpotifyClient() as client:
    track = client.get_track("https://open.spotify.com/track/4uLU6hMCjMI75M1A2tKUQC")
    print(track.name, "-", track.artists[0].name)
    print(track.duration_ms, "ms |", track.preview_url)

If you prefer dictionaries, track.to_dict() returns a JSON-safe one. For concurrent work, the async client is used the same way, and asyncio.gather runs several lookups at once.

python
import asyncio
from spotify_scraper import AsyncSpotifyClient

async def main():
    async with AsyncSpotifyClient() as client:
        track, album = await asyncio.gather(
            client.get_track("4uLU6hMCjMI75M1A2tKUQC"),
            client.get_album("6N9PS4QXF1D0OWPk0Sxtb4"),
        )
        print(track.name, "|", album.name)

asyncio.run(main())

The same client can download assets. download_cover writes cover art to a destination directory, and download_preview accepts an embed_cover flag, though the README notes that path needs the media extra. There is also a container image: the Dockerfile serves the MCP server over streamable-HTTP on port 8000 by default, and setting SPOTIFY_SP_DC enables the authenticated tools. Overriding the command runs the CLI instead.

Where SpotifyScraper is the wrong tool

The boundary is read-only public data, and the README's comparison table marks write, playback and private data as unsupported. If your feature is adding a track to a user's queue or reading their saved albums, the official API is the only route, and no amount of scraping substitutes for it.

The second limitation is market accuracy. Because anonymous Spotify resolves country from the request IP and ignores a market variable, you cannot ask for availability in a specific market, and preview URLs do not vary by region. Anything that must reflect a particular storefront is out of scope.

The third is data that no longer exists. The README notes that Spotify's audio-features, recommendations and related-artists endpoints have returned 403 for new apps since November 2024, and that SpotifyScraper still returns related artists and recommendations without a key. It also states that audio-features cannot be brought back, because Spotify removed that data entirely. If your pipeline depends on tempo or energy values, this project will not recover them.

Finally, the project classifies itself as Beta in pyproject.toml and the README points v2 users to a migration guide, with the previous line kept on the v2.x branch. That is a signal to pin a version and read the changelog before upgrading, not to assume the API is frozen.

SpotifyScraper versus spotipy and the Apify-style scrapers

The README positions spotipy as the main alternative, and the difference is architectural rather than cosmetic. spotipy wraps the official Web API, so it requires an app registration and an OAuth flow, but it can write to an account and read private or library data. SpotifyScraper reads what the web player already exposes, so setup disappears, but the capability set shrinks to public metadata, lyrics and previews. The README also lists sync and async support, fully typed immutable models, lyrics and podcast transcripts behind a cookie, and an MCP server as things spotipy does not offer, while conceding that authenticated writes and market-accurate data go the other way.

The hosted scrapers people find through search, the Apify and RapidAPI style services, take a different approach again: someone else runs and maintains the extraction, and you pay per call or per month. That removes the maintenance question but adds a vendor, a network hop and a pricing model. SpotifyScraper is a library you install and run yourself, with the failure modes that implies.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-09-03, which is recent. The latest release listed is v3.9.2 from 2026-06-26, following v3.9.1 and v3.9.0 a few days earlier in June, so the 3.9 line moved quickly in that window. The README badge states the project is maintained with Claude Code, and the repository carries a CLAUDE.md file and a .claude directory alongside an openspec directory, which suggests the spec and agent workflow are part of the source tree rather than an afterthought.

Upgrade cost concentrates in two places. The httpx dependency is pinned below 1.0 with a comment explaining why, so a future httpx 1.0 will require a deliberate bump. And the v2 to v3 transition already forced a rewrite; the migration guide exists for that reason. Pin your version and read CHANGELOG.md before moving.

The licence is MIT, declared both in pyproject.toml and as a LICENSE file, and the Dockerfile labels the image with the same identifier. That permits commercial use and modification, but it also means no warranty. Note separately that the data you extract is Spotify's, and the licence covers the code, not the content. That is a question for your own legal review, not something the repository settles.

Editorial conclusion

Adopt SpotifyScraper if you need public Spotify metadata, cover art or previews in Python and do not want to register an app or run an OAuth flow. Skip it if you need writes, playback control, private library data, or market-accurate availability, because the README states the client is read-only public data and that a market variable is ignored. Before committing, verify the anonymous token bootstrap against a few real links and check the current release on PyPI, since the project is still classified as Beta.

Frequently asked questions

Does SpotifyScraper need an API key or a Spotify login?

No key is needed for public data. The README states that SpotifyScraper bootstraps an anonymous token from Spotify's public embed pages, and that only the opt-in logged-in features (lyrics, podcast transcripts and account info) require your own sp_dc cookie, never a password or API key.

Can SpotifyScraper write to a Spotify account or control playback?

No. The README's comparison table marks write, playback and private data as unsupported, describing the library as read-only public data. Use spotipy for authenticated writes and private, market-accurate data.

Does the locale parameter change which tracks SpotifyScraper returns?

No. The README says locale is a BCP-47 language tag sent as the Accept-Language header, and that it changes only how display names are spelled. It is not a country or market code, a bare "US" is ignored, and it does not filter regional availability or vary preview URLs.

Official sources

  1. AliAkhtari78/SpotifyScraper on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Community notes

Community notes