Spotify Web API

Spotify Web API is Spotify's own developer interface to its streaming catalog - the Interactive Media Services slice's deepest single-source body of music metadata. Its documented object model covers tracks, artists, albums, playlists, shows, episodes and audiobooks, plus search, recommendations and user-library endpoints. What turns that into a dataset is the shape: every track resolves through one stable ID, dressed with an embedded album object carrying release date at year, month or day precision, an array of artist records each holding its own ID and URI, industry identifiers including ISRC, EAN and UPC, duration in milliseconds, an explicit-lyrics flag, and market availability spelled out per ISO 3166-1 country code.

Then there is the layer nobody else measures the same way: the Audio Features object. Every track carries a vector scored by the platform's own analysis - danceability, energy, valence, acousticness, speechiness, instrumentalness, liveness, tempo, key, mode, time signature and loudness. In the published example, one track lands at 0.585 danceability, 0.842 energy, 118.211 BPM in A minor. That is a labeled, machine-readable description of how recorded music actually sounds, attached to a global catalog and joinable on the same ID that everything else uses.

One honesty note up front: the source's documentation flags several long-standing fields as deprecated - popularity, available_markets, preview_url among them. They still arrive in records, but treating them as load-bearing without a fallback is how reports break quietly.

Audio features first, quoted from published response examples exactly as documented:

id           : 2takcwOaAZWiXQijPHIx7B   type      : audio_features
danceability : 0.585                    energy    : 0.842
valence      : 0.428                    tempo     : 118.211 bpm
key          : 9 (A)                    mode      : 0 (minor)
loudness     : -5.883 dB                time_sig  : 4

And the identity half of the same track:

album_type   : compilation              released  : 1981 (year precision)
total_tracks : 9                        duration_ms : 237040
explicit     : false                    external_ids : isrc / ean / upc
uri          : spotify:track:<id>       popularity: deprecated, retained

Read together, the design shows itself: identity fields locate the track everywhere - your ISRC joins our ID joins the URI - while the feature block turns subjective descriptors like "upbeat" or "chill" into columns you can sort, bucket and regress. Note the release precision flag: this compilation knows only its year, other releases know their day. Precision is a per-record attribute, not a promise.

Nineteen fields form the verified spine of a track record, every definition traced to the source's own documented object model rather than inferred. Identity keys (id, uri, external_ids), release context (album with its precision flag, artists, duration_ms, explicit) and the twelve-surface audio-feature vector all travel on the same row, joined by one ID.

Three further surfaces are documented to exist but change shape record to record - the finer-grained audio-analysis payload, recommendation output against seed tracks, and playlist item structure - so their delivered forms sit under additional fields on request below rather than in confident prose here. The dictionary table repeats the spine in tabular form.

• Geography - one global catalog with regionality as a column, not a wall. Market availability travels per record as ISO 3166-1 alpha-2 country codes, so the same track can be sliced by where it lists and where it skips - useful for release-strategy work, though the source itself notes the market-listing field is among those flagged deprecated.
• Temporal - current-state only. Release dates carry year, month or day precision depending on what the release declares, and there is no historical archive behind the catalog: no past charts, no removed-track graveyard. If your study needs trailing history, scheduled collection accumulates it at whatever cadence you pick.
• Granularity - object level throughout: one row per track, artist, album, playlist or show, with audio features and the deeper analysis resolving at individual track level. Per-track resolution is precisely what recommendation models and mood-mapping need; aggregates would average away the variance they run on.

The honest caveat: no aggregate size is published for the catalog. Coverage is defined by reachability - object by object - not by a headline count, and a scoped sample settles quickly how deep any given corner goes.

API, files, or your warehouse. Daily, weekly, or hourly.

You choose the channel and the cadence; the nineteen-field spine above travels unchanged through all three. Responses' raw nesting never reaches your pipeline - rows arrive flattened to one observation per track with the feature vector already exploded into columns and identifiers already normalized, so your ISRC keys line up against ours without a matching project. Cadence changes are a settings conversation, not a re-integration, and a sample cut to your artist or track list comes first either way.

• Data scientists and ML engineers train recommendation, mood-tagging and genre-classification models on a per-track feature corpus keyed by one stable ID - relevance 2 in their pack.
• Developers and builders power discovery, search and playlist features on documented object schemas instead of reverse-engineering pages - also relevance 2.
• Competitive-intel and product teams watch roster moves, release patterns and market availability across the streaming landscape - relevance 2, more framings on our competitive intel product teams use cases page.
• Market researchers and consultants quantify how genres, tempos and moods shift across release years for trend and industry reporting.
• Investors and quants read catalog depth and release velocity around artists and labels as engagement context ahead of reported numbers.
• Journalists and academics ground music-culture claims in measured audio features instead of anecdote - "sad girl autumn" becomes a valence series with a start date.

Data scientists hold this at relevance 2 in their interactive-media-services pack - the audio-feature vector is the rarest thing in the slice: measured attributes, not borrowed opinions, attached to a global catalog. Developers and builders match at relevance 2 on the strength of the documented object model; stable IDs make integration boring in the good way. Competitive-intel teams also score 2, using release footprints and roster structure as market signals. Market researchers, investors and journalists hold relevance 1 but get angles nobody else can buy: trend lines drawn from measured sound rather than chart positions alone. The constant across all six is the ID - everything compounds when joined on the same track key.

Four things, all knowable upfront. First, this is a current-state catalog: release dates yes, historical archives no - if you need trailing history, say so and let scheduled collection build it at your chosen cadence. Second, several long-standing fields carry deprecation flags in the source's own documentation, with no removal dates announced; we deliver them as observed and flag them in the schema so nothing leans on them silently. Third, release-date precision varies record to record - some rows know the day, some only the year - so treat precision as a per-record attribute in any timeline work. Fourth, the richest surfaces (full analysis payloads, recommendation output, playlist structure) vary in shape by record, which is why they fold under additional fields on request: a sample verifies exactly which columns populate for your artists and tracks before anything is built on them.