How to Get User Listening Data for a Wrapped Feature: Spotify, Apple Music, Last.fm, and ListenBrainz Compared

What Listening Data a Wrapped Feature Actually Needs

To pull a user's listening history for a Wrapped-style recap, you can use the Spotify Web API, the Apple Music API (MusicKit), the Last.fm API, or ListenBrainz. If the recap is about activity inside your own app, use your own in-app event data instead. A Wrapped-style feature is a personalized year-in-review that shows a user their top artists, top tracks, and listening totals for the year.

That first choice matters more than the API you pick. A recap can draw on two kinds of data: a music streaming service's API, or your app's own activity log. Pick the wrong one and you will spend days wiring up an API that can never return the numbers your recap is supposed to show.

Getting that branch right saves you weeks. A music service can tell you a user's top artists and favorite tracks. It cannot tell you how many lessons they finished or how long their streak ran. Those numbers only exist in your own database.

Most guides skip straight to Spotify and stop there. This one covers all four music APIs, explains the real limits of each, and shows when your own data is the better source. Read it if you build apps and want an honest map before you write any code.

Spotify Web API: Endpoints, Scopes, and OAuth

Spotify gives you two endpoints that return Wrapped-style data. Get User's Top Items returns a user's top artists or tracks at /me/top/{artists|tracks}, with three time ranges: short_term (4 weeks), medium_term (6 months), and long_term (~1 year), up to a maximum of 50 items. Get Recently Played Tracks returns a user's recent plays at /me/player/recently-played, capped at a maximum of 50 items.

That 50-item cap on recently played is the catch. It is a rolling window of the last few plays, not a full-year history. If you want a year of listening, the top-items endpoint with the long_term range is your source, not recently played.

Spotify also does not expose raw per-user play counts. Top items come back affinity-ranked, so you get an ordered list of what a user listens to most, without the exact number of times they played each track. Affinity ranking is Spotify's own measure of how strongly a user favors an artist or track, based on signals it does not publish.

That shapes what you can honestly promise a user. You can say "your top artist this year," and you can order a top-five list. You cannot say "you played this song 412 times," because Spotify never hands you that figure. Write your recap copy around rankings, and you avoid claims the data cannot back up.

For access, Spotify uses OAuth 2.0. Use the Authorization Code flow for server-side apps, or Authorization Code with PKCE for mobile apps and single-page apps. OAuth is the standard that lets a user grant your app permission without sharing their password. PKCE is a variant that keeps the flow safe on clients that cannot hide a secret key, like a phone app or browser code.

You need two scopes, user-top-read and user-read-recently-played, which are the permissions that unlock the two endpoints above. A scope is the specific slice of a user's account your app asks to read. Request only these two, and users see a clear, narrow permission screen instead of a broad one.

Spotify Quota Modes, Limits, and the February 2026 Access Changes

New Spotify apps start in development mode, which allows up to 5 authenticated Spotify users who must be added to an allowlist by hand. A quota mode is the access tier that sets how many users your app can serve. Development mode is fine for a prototype, but 5 users will not cover a public launch.

To go public you apply for extended quota mode, which removes the allowlist and lets unlimited users connect. The catch is time: Spotify says the review "can take up to six weeks," so start it well before your launch date. There is a harder catch on eligibility. As of May 15, 2025, Spotify only accepts extended-quota applications from organizations, meaning a legally registered business, not individuals. It also requires a minimum of 250,000 monthly active users. Many indie developers and small teams will not qualify, which is a real reason to recap your own in-app data instead.

The February 2026 developer-access update tightened development mode further. It now requires a Spotify Premium account, limits each developer to one development-mode Client ID, and caps that Client ID at up to five authorized users. A Client ID is the identifier Spotify assigns to your app when you register it.

The practical takeaway is simple. Any public-facing Spotify Wrapped feature needs extended quota mode, so build the six-week review window into your timeline.

There is a seasonal wrinkle here too. Wrapped features tend to launch in December, which means your extended-quota review has to clear in the fall. If you wait until November to apply, the six-week window can push your launch past the moment users expect their recap.

Apple Music API and MusicKit

If your users listen on Apple Music, the Apple Music API is the path. MusicKit can retrieve a user's recently played content and Apple Music Replay summary, Apple's own year-end recap of a user's top songs, albums, and artists. Replay is the closest native equivalent to Spotify Wrapped, and it maps neatly onto a year-in-review feature.

Access uses two tokens. A developer token identifies your app, and a Music User Token authorizes access to a specific user's library and history.

You reach these APIs through MusicKit, which is available for Apple platforms, Android, and the web. That cross-platform reach means you are not locked to iOS. You can build the same recap for an Android user or a web visitor, as long as they have an Apple Music subscription.

The honest trade-off is scope. Apple Music is the natural choice only for apps whose users actually listen on Apple Music, not Spotify or anywhere else. If your audience is split across services, one Apple integration will leave a chunk of users with an empty recap.

Last.fm API: Cross-Platform Scrobbling

Last.fm is the platform-agnostic option. It aggregates a user's listening across many services through scrobbling, where a "scrobble" is a logged record that a user played a track. Because scrobbles come from Spotify, Apple Music, and other players, Last.fm can recap a user who does not live on a single service.

Two read methods do most of the work for a recap. user.getTopArtists and its sibling user.getTopTracks return top items with period options overall, 7day, 1month, 3month, 6month, and 12month. The 12-month period maps directly onto a Wrapped recap, so you can pull a clean year of top artists and tracks in one call.

Access is lighter than Spotify's. Last.fm read calls need only an API key, not a full user OAuth flow, so you can fetch public listening stats without asking each user to log in.

The trade-off is data quality. A scrobble only counts when the track is longer than 30 seconds and has played for at least half its duration or 4 minutes. A recap is only as complete as the user's scrobbling habit, so a user who never connected their player will have thin data.

That dependency shapes who Last.fm is good for. It shines for music enthusiasts who already scrobble across several apps and want one combined history. It disappoints casual listeners who never set it up, since there is nothing for the recap to summarize.

ListenBrainz: The Open Alternative

ListenBrainz is the open, non-commercial choice. Run by the MetaBrainz Foundation, it is a public listening-history database with a statistics API and downloadable data dumps, which means the data is not locked behind one company's terms.

Access uses a user token, and the rate limit is strict: the docs say to "never make more than ONE call per second." ListenBrainz fits privacy-first projects, open-data work, and users who avoid the big commercial services.

The one-call-per-second limit is worth planning around. If you generate recaps for many users at once, queue the requests and cache what you fetch, or you will hit the ceiling fast. This matters most on launch day, when a rush of users open their recap in the same hour.

The trade-off is reach and effort. ListenBrainz has a smaller user base than Spotify or Apple Music, and you handle more of the data plumbing yourself. For an open-data recap that respects users who opt out of commercial platforms, it is worth the extra work.

Side-by-Side Comparison of the Music APIs

Here is every option in one view. The rows match the sections above, so the trade-offs line up with what you just read. Scan the "Best for" column first, then check the limits and restrictions before you commit.

API	Data available	Authentication	Key limits / quota	Commercial restrictions	Best for
Spotify Web API	Top artists/tracks (short_term ~4 weeks, medium_term ~6 months, long_term ~1 year); recently played; affinity-ranked, no raw play counts	OAuth 2.0 (Authorization Code or PKCE); scopes user-top-read, user-read-recently-played	Top items and recently played max 50 items; development mode up to 5 users; extended quota review up to six weeks	Attribution required; no metadata/cover art as a standalone product; no training AI on Spotify Content	Apps whose users listen on Spotify and can clear extended quota
Apple Music API / MusicKit	Most-recently played content, History resource, Apple Music Replay (top songs, albums, artists)	Developer token plus Music User Token	Governed by Apple Media Services terms	Apple developer and media terms apply	Apple Music listeners; MusicKit runs on Apple platforms, Android, and the web
Last.fm	Top artists/tracks with periods overall, 7day, 1month, 3month, 6month, 12month; cross-service scrobbles	API key for read calls (no user OAuth)	Scrobble counts only if track > 30s and played half its length or 4 min	Last.fm API terms apply	Cross-platform recaps that span multiple services
ListenBrainz	Open listening history and statistics; public data dumps	User token	No more than one call per second	Open, non-commercial data (MetaBrainz)	Privacy-first and open-data projects
Your own in-app data (Trophy)	Days active, top day/week/month, achievements, longest streak, full-year metrics	Trophy API/SDK keys	Usage-based; supports over 24M streaks across customers	Your data, your terms	Recaps of what users did inside your app

Licensing and Commercial Restrictions to Watch

Music data comes with legal strings, and Spotify's are the ones people miss. Spotify's Developer Policy requires attribution of Spotify Content, and it says you "must not offer metadata, cover art ... as a standalone service or product." It also prohibits training AI or ML models on Spotify Content and limits how you store content.

The practical takeaway: read each provider's terms before you ship a commercial Wrapped feature, especially if you plan to store or redistribute data. What is fine for a weekend project can break the rules once you charge for it.

The storage limit deserves a second look before launch. If your recap caches a year of tracks and cover art to render quickly, you may bump into the terms on how long you can hold that content. The safest read is to treat the music service as the source of truth and fetch on demand, rather than warehousing its data.

This is one reason many teams recap their own activity data instead. When the data is yours, the licensing question mostly goes away.

When Your Data Source Should Be Your Own App

If the recap is about what users did inside your app (lessons finished, workouts logged, words written, streaks kept), a music API is the wrong tool. That data already lives in your product, so pulling it from Spotify or Last.fm makes no sense. The honest move is to recap your own tracking user activity.

Building that year-in-review pipeline in-house is real work. You write the aggregation logic, compute highlights and percentiles, handle timezone-aware windows, and survive the launch-day traffic spike when everyone opens their recap at once. Trophy's own estimate for building this from scratch is 6-10 weeks.

That estimate is not padding. Each piece looks small until you add the others: percentile math needs the full population, highlight logic needs tie-breakers, and the whole thing has to stay correct as new activity streams in all year. The build is where many teams decide whether to buy the pieces instead.

Trophy is gamification infrastructure that already stores timestamped in-app activity, so the aggregation is done for you. Its Wrapped API for consumer apps turns a year of tracked activity into a recap: GET /v1/users/{id}/wrapped returns days active, top day, week, and month, full-year metrics, achievements, and longest streak. Type-safe SDKs ship in seven languages: Node.js, Go, Java, .NET, PHP, Python, and Ruby.

The timezone problem is the one that quietly eats engineering time. A "day active" in Tokyo starts hours before a "day active" in Los Angeles, and your longest-streak math has to respect each user's local midnight. Get it wrong and users see broken streaks and off-by-one totals in the recap they were most excited to share.

Scale is the part most teams underestimate. Trophy already aggregates over 24M streaks across customers, so the timezone edge cases and launch-day load are handled. If you want to see the shape of the work first, here is how to build a Wrapped feature from your own data.

How to Choose the Right Data Source

Match the source to your users and your recap. Use Spotify if your users listen on Spotify and you can clear extended quota, and use Apple Music/MusicKit if they listen on Apple Music. Use Last.fm or ListenBrainz for cross-platform or open-data recaps, and use your own event data (Trophy) when the recap is about in-app behavior.

The one-line test: if the story is about music, pick the music service your users actually use; if the story is about your product, the data is already yours. For a fuller build checklist, see these tools to build a Wrapped feature.

One more note on mixing sources. Nothing stops you from combining a music recap with your own in-app stats in the same feature, as long as you respect each provider's terms. Just be clear with yourself about which part of the recap each source owns before you start wiring it up.

Frequently Asked Questions

Does Spotify allow APIs?

Yes. Spotify publishes a Web API with user-listening endpoints for top items and recently played tracks, subject to its quota modes and developer terms.

Can I get the Spotify API for free?

Yes, in development mode, but it now requires a Spotify Premium account and is capped at up to five authorized users; a public feature needs extended quota mode.

What authentication method should I use?

Spotify uses OAuth 2.0 (Authorization Code, or Authorization Code with PKCE for mobile and single-page apps) with the user-top-read and user-read-recently-played scopes; Apple uses a developer token plus a Music User Token; Last.fm read calls need only an API key; ListenBrainz uses a user token.

Are there commercial restrictions on using Spotify content?

Yes. Spotify's Developer Policy requires attribution, forbids offering its metadata or cover art as a standalone product, and prohibits training AI models on Spotify Content.

Can I get exact play counts from Spotify?

No. Top items are ranked by affinity and recently played is capped at 50 items, so Spotify does not return raw per-user play counts.

Which API works across multiple streaming services?

Last.fm (via scrobbling) and ListenBrainz aggregate listening from more than one service, which makes them the cross-platform options.