Your cart is currently empty!
How to Scrape Apple Music Charts and Playlists (2026)
Apple Music doesn’t hand out a public API, which makes scraping Apple Music charts and playlists more interesting than most music data projects. If you need chart rankings, editorial playlist metadata, or track-level data at scale in 2026, you have three realistic paths: the MusicKit JS/REST API (limited but legit), Apify actors built for Apple Music, or direct HTML scraping of the charts pages. Each has real tradeoffs worth understanding before you commit.
What Data Is Actually Extractable
Apple Music exposes more than most engineers expect — without a paid developer account.
The public charts at music.apple.com/us/charts render server-side HTML for top songs, albums, and music videos by country. Each chart entry includes track title, artist name, album name, chart position, artwork URL, and a canonical Apple Music URL. Playlist pages (editorial playlists like “Today’s Hits”) are similarly crawlable and include track order, contributor metadata, and playlist description.
What you won’t get without authentication: play counts, listener counts, skip rates, or any user-generated behavioral data. Apple Music keeps that locked behind their developer tier. If you need engagement signals, How to Scrape Last.fm Listening Data and Artist Metadata (2026) is worth reading alongside this — Last.fm’s scrobble data can proxy for listener behavior Apple doesn’t expose.
Option 1: MusicKit API (The Official Route)
Apple’s MusicKit REST API is available to registered Apple Developer Program members ($99/year). It returns clean JSON and covers charts, playlists, search, and catalog lookups.
A charts request looks like this:
import requests
headers = {
"Authorization": f"Bearer {DEVELOPER_TOKEN}",
"Music-User-Token": user_token # optional, for personalized endpoints
}
resp = requests.get(
"https://api.music.apple.com/v1/catalog/us/charts",
params={"types": "songs", "limit": 50, "genre": "14"}, # genre 14 = pop
headers=headers
)
data = resp.json()
for item in data["results"]["songs"][0]["data"]:
print(item["attributes"]["name"], item["attributes"]["artistName"])
Rate limits are not publicly documented, but community reports suggest roughly 20 requests/second per token before you start seeing 429s. Developer tokens expire after 6 months and must be signed with your private key using ES256.
The main limitation: MusicKit only returns chart data for supported storefronts (about 60 countries), and playlist contents for editorial playlists require knowing the playlist ID in advance. There’s no endpoint to list all editorial playlists.
Option 2: HTML Scraping the Charts Pages
For teams without a developer account or needing broader coverage, the HTML route works reliably in 2026. Apple’s charts pages are server-rendered, which means requests + BeautifulSoup is sufficient — no headless browser needed for the initial data.
from bs4 import BeautifulSoup
import requests
url = "https://music.apple.com/us/charts"
headers = {"User-Agent": "Mozilla/5.0 (compatible; research-bot/1.0)"}
resp = requests.get(url, headers=headers)
soup = BeautifulSoup(resp.text, "html.parser")
chart_items = soup.select(".chart-lockup__details")
for item in chart_items:
title = item.select_one(".chart-lockup__title").get_text(strip=True)
artist = item.select_one(".chart-lockup__subtitle").get_text(strip=True)
print(title, "|", artist)
A few practical notes:
- Apple does fingerprint user agents. Rotate between realistic browser UA strings, not generic bot strings.
- Country-specific charts are at
music.apple.com/{country-code}/charts—gb,au,jp, etc. - The selector structure changes 2-3 times per year. Build a selector test into your pipeline and alert on empty results.
- For playlist pages, the track list is embedded as a JSON-LD
block, which is far easier to parse than the HTML structure.
Option 3: Apify and Third-Party Actors
If you're running infrequent scrapes or want managed infrastructure, Apify's Apple Music actors handle the rotation, retries, and selector maintenance for you.
| Tool | Coverage | Pricing | Freshness | Custom Filters |
|---|---|---|---|---|
| Apify Apple Music Scraper | Charts + playlists | ~$3-8 per 1K results | Near real-time | Country, genre |
| MusicKit API | Charts + catalog | $99/yr dev fee | Real-time | Genre, storefront |
| DIY HTML scraper | Charts only | Infra cost only | On-demand | Full control |
| ScrapingBee/Zenrows | Charts (with JS render) | $50-150/mo | On-demand | Full control |
Apify makes sense for ad-hoc research. DIY makes sense for daily chart tracking pipelines. MusicKit is the right call if you need catalog metadata (ISRC codes, release dates, genre IDs) reliably.
Compare this to How to Scrape Spotify Public Data (2026): Playlists, Artists, Charts -- Spotify's official API is more permissive and covers a lot more use cases without requiring credit card authentication, which makes it a better starting point if platform-agnostic chart data meets your needs.
Handling Anti-Bot Measures
Apple Music's anti-bot posture is moderate -- not as aggressive as Ticketmaster or LinkedIn, but not as open as How to Scrape SoundCloud Artist + Track Data (2026). The main signals Apple checks:
- TLS fingerprint (use
curl_cffiorhttpxwith browser impersonation rather than plainrequestsat scale) - Request cadence -- anything faster than 1 req/second from a single IP triggers soft blocks
- Datacenter IP ranges -- residential or mobile proxies work significantly better than datacenter IPs for sustained scraping
Recommended proxy setup for chart monitoring:
- Use residential proxies for initial discovery and any request that triggers a Cloudflare challenge.
- Cache chart data aggressively -- charts update once per day at most, so re-scraping every 15 minutes is waste.
- Stagger country requests across a 30-60 minute window rather than hammering all 60 storefronts back-to-back.
- Store raw HTML alongside parsed output so selector changes don't lose historical data.
For artists tracking their cross-platform presence, combining Apple Music chart data with How to Scrape Bandcamp Artist Pages and Sales Data (2026) gives a useful indie vs. mainstream signal.
Parsing Playlist JSON-LD
Editorial playlist pages embed structured data that's cleaner to work with than the rendered HTML:
import json, re
script_tags = soup.find_all("script", type="application/ld+json")
for tag in script_tags:
data = json.loads(tag.string)
if data.get("@type") == "MusicPlaylist":
print(data["name"])
for track in data.get("track", []):
print(" -", track["item"]["name"], "/", track["item"]["byArtist"]["name"])
This approach is far more stable than CSS selector scraping and survives most frontend refactors. Apple's JSON-LD output follows schema.org MusicPlaylist fairly closely, with numTracks, description, image, and nested MusicRecording items per track.
Useful fields you'll find in the JSON-LD:
track[].item.duration-- ISO 8601 duration string (e.g.,PT3M42S)track[].item.@id-- canonical Apple Music URL for the tracktrack[].item.byArtist.@id-- canonical artist URL, useful for deduplicationimage[].url-- playlist artwork at multiple resolutions
Bottom Line
For most data teams in 2026, the pragmatic path is JSON-LD parsing for playlists combined with lightweight HTML scraping for daily chart positions, using residential proxies if you're hitting more than 10 storefronts. The MusicKit API earns its $99/year fee only if you need ISRC codes or catalog metadata at volume. DRT will keep covering the practical mechanics of music data collection as Apple's infrastructure evolves -- bookmark the site if you're building in this space.
Leave a Reply