How to Scrape iTunes Search: Songs, Apps & Podcasts 2026

Apple runs one of the largest media catalogs on earth — music, podcasts, apps, movies, ebooks, audiobooks — and it exposes a public search API that its own apps use. The friction isn’t access; it’s scale and shape. The endpoint hard-caps every request at 200 results with no pagination, returns a different subset of fields for every media type, and buries the useful data in raw API keys. This guide covers how the iTunes Search and Lookup APIs actually work, what you can pull for each entity type, and how to turn a list of search terms or IDs into a clean, multi-country dataset — no Apple ID, no developer account, no key.

What’s worth extracting

Each result row carries 20+ fields. The useful ones, grouped:

• Identity and type — wrapperType (track, collection, artist), kind (song, podcast-episode, software, feature-movie, etc.), trackId (the unique numeric iTunes ID), trackName, artistName (artist, developer, or author), and collectionName (album, show, or collection).
• Classification — primaryGenreName (e.g. Pop, Business, Entertainment) and contentAdvisoryRating (Explicit, 4+, PG-13, Clean).
• Pricing — trackPrice, collectionPrice, and currency (3-letter ISO code, always the store’s local currency).
• Ratings — averageUserRating (0–5) and userRatingCount. These populate for apps and podcasts, typically not for music tracks.
• Timing and media — releaseDate (ISO 8601), trackTimeMillis (duration in ms for songs and episodes), artworkUrl100 (100×100 px art), and trackViewUrl (direct store link).
• Detail and provenance — description (apps, podcasts, ebooks), country (store code), searchTerm (the term that produced the row, search mode), and entity (the entity type used).

Which fields populate depends entirely on the media type — apps carry ratings and descriptions, songs carry duration and album prices. Null fields are how the Apple API works, not a scraper defect.

How the source actually works

The actor hits two official, keyless Apple endpoints — the ones Apple’s own apps rely on, which makes them stable and high-throughput:

https://itunes.apple.com/search    # keyword search
https://itunes.apple.com/lookup    # exact lookup by iTunes ID

Search mode takes a list of terms plus an entity type and a country, and returns up to 200 results per term. Terms run concurrently (up to 5 parallel workers), so a list of 50 artists can yield 10,000 rows in one run:

{
  "mode": "search",
  "terms": ["taylor swift", "drake", "billie eilish"],
  "entity": "musicTrack",
  "country": "US",
  "maxResults": 200
}

Lookup mode takes iTunes IDs and returns one row per ID, batching up to 200 IDs per call automatically for larger lists — the exact-match path when you already have IDs:

{
  "mode": "lookup",
  "ids": ["1440818588", "1193701556", "909253"],
  "country": "US"
}

The entity field is the lever that changes everything. Search python with entity=software and you get App Store apps; search the same word with entity=ebook and you get programming books. Supported entities: musicTrack, album, song, podcast, software, movie, ebook, audiobook, tvSeason. The country field is any ISO 3166-1 alpha-2 code and controls both catalog availability and the currency prices come back in.

▶ Open the iTunes Search Scraper on Apify — one run turns a list of terms or IDs into thousands of Apple media rows across any store country. Keyless, no login. Export to CSV, JSON, Excel or XML.

The access reality

There’s no anti-bot wall — this is a public API. The friction is its hard limits and per-type inconsistency:

• 200 results per request, no pagination. This is the big one. The iTunes API caps each request at 200 rows and offers no paging. To go deeper on a popular term, you split it into more specific sub-terms (taylor swift folklore, taylor swift lover, …) rather than paging.
• Per-type field gaps. trackTimeMillis populates for songs and episodes but not ebooks; averageUserRating appears for apps and podcasts but not music tracks. Every entity type populates a different subset — plan your schema for nulls.
• Country is the currency and catalog switch. Prices always return in the store’s local currency (GBP for country=GB, JPY for country=JP). The JP store also carries a different catalog and different pricing than US — run the same term across countries to compare.
• Freshness. The API returns live catalog data — current prices and ratings — so it’s real-time as of the request.

The naive approach — one search call — hits the 200-row ceiling immediately and gives you no strategy for going deeper. The actor’s concurrency and term-batching turn that limit into a workable dataset by fanning out across many terms.

Example output

One fully-populated podcast row:

{
  "wrapperType": "track",
  "kind": "podcast",
  "trackId": "1200361736",
  "trackName": "How I Built This with Guy Raz",
  "artistName": "NPR",
  "primaryGenreName": "Business",
  "releaseDate": "2016-09-05T04:00:00Z",
  "trackPrice": "-1",
  "currency": "USD",
  "country": "US",
  "trackViewUrl": "https://podcasts.apple.com/us/podcast/how-i-built-this/id1200361736?uo=4",
  "artworkUrl100": "https://is2-ssl.mzstatic.com/image/thumb/.../100x100bb.jpg",
  "description": "Guy Raz dives into the stories behind some of the world's best known companies...",
  "averageUserRating": "4.8",
  "userRatingCount": "43210",
  "contentAdvisoryRating": "Clean",
  "searchTerm": "entrepreneurship",
  "entity": "podcast"
}

Note trackPrice of -1 for a free podcast — a sentinel value, not a real price. Handle it downstream.

Typical use cases

Who pulls iTunes data and for what:

• Music research — track discographies across thousands of artists: title, price, genre, releaseDate, and album grouping via collectionName.
• App Store monitoring / ASO — scrape software results for keyword searches, schedule weekly, and diff averageUserRating and userRatingCount to track competitor apps over time.
• Podcast directory building — scrape the podcast entity across 100+ topic keywords to assemble a catalog with ratings and descriptions.
• Cross-country price comparison — run the same term with country=US, GB, JP and compare pricing and catalog availability.
• Dataset enrichment — collect trackId values from a search run, then re-run in lookup mode for exact, complete metadata on those IDs.
• Data journalism — study Apple’s catalog, pricing trends, or content-advisory patterns across countries.

Cost and effort: build vs. managed

The API is keyless, so a one-off script is trivial. What isn’t trivial is the production shape: concurrent fan-out across many terms to work around the 200-row cap, automatic ID batching for lookup, per-entity field normalization, retry on transient errors, multi-country runs, and scheduling for rating/price tracking. That’s the difference between “I got 200 songs once” and “I have a refreshing dataset across 50 artists and three stores.”

The managed actor is pay-per-result: a small per-run start fee plus a fraction of a cent per row, no subscription. With 5 concurrent workers on datacenter proxy, the README puts 50 terms and ~10,000 rows at under two minutes. Because you pay per row, a focused single-term probe is nearly free before you scale to a broad multi-term, multi-country sweep.

Common pitfalls

Specific to the iTunes API:

• The 200-row cap is real and has no workaround via paging. Deeper coverage of a popular term requires more specific sub-terms, not a bigger maxResults — the API caps at 200 per request regardless.
• Null fields are expected, per type. Don’t treat a missing averageUserRating on a song or a missing trackTimeMillis on an ebook as an error. Design for it.
• trackPrice sentinels. Free items can return -1 or null rather than 0. Normalize before you sum or average prices.
• Entity choice determines meaning. The same term returns apps, books, or songs depending on entity. Set it deliberately — a wrong entity is the top cause of “unexpected results.”
• Country changes both catalog and currency. Comparing prices across stores requires normalizing currency yourself; the API won’t convert.
• Everything is a string. Numeric fields (trackPrice, averageUserRating, trackTimeMillis) arrive as strings. Cast on ingest.

Wrapping up

The iTunes Search API is a rich, keyless, real-time source for Apple media — the catch is the 200-row-per-request cap and the per-type field inconsistency, both of which shape how you query. If you’d rather fan out across many terms and countries and get clean, normalized rows without building the concurrency and batching layer yourself, the managed actor does it.

▶ Run the iTunes Search Scraper on Apify — one run returns thousands of songs, apps, podcasts, movies or ebooks with price, rating, genre, artwork and store URL across any country. Keyless, no login. Export to CSV, JSON, Excel or XML. Start on Apify’s free monthly credit.