Apple Podcasts New-Episode Monitor avatar

Apple Podcasts New-Episode Monitor

Pricing

from $17.00 / 1,000 podcast shows

Go to Apify Store
Apple Podcasts New-Episode Monitor

Apple Podcasts New-Episode Monitor

Apple Podcasts Monitor that returns show metadata, feed URL, episode titles and audio links. 15 show fields, 12 episode fields. Get told when a show publishes. Export to JSON, CSV or Excel, run it on a schedule, or call it from the Apify API.

Pricing

from $17.00 / 1,000 podcast shows

Rating

0.0

(0)

Developer

angel nguyen

angel nguyen

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

22 days ago

Last modified

Share

What this Actor does

Apple Podcasts search plus each show's real RSS feed: get a typed row for every show you watch and one for every episode it publishes, with titles, publication dates, durations and direct audio URLs. Point it at a watchlist, schedule it, and turn on newEpisodesOnly to be told only about episodes you have not seen.

Actor icon

The two halves matter separately. Apple's directory is how you find a show and get its canonical feed URL; the feed itself is how you get episodes, because Apple's directory does not carry them. This Actor does both in one pass and hands you rows from each.

Key features

  • Two ways in. Free-text search terms for discovery, or Apple podcast collection IDs for a fixed watchlist. IDs use the robots-allowed /lookup path and are the recommended input for anything scheduled.
  • Canonical feed resolution. Every show row carries feedUrl — the show's real RSS feed as Apple publishes it — so you are not guessing at a URL.
  • Episodes with playable audio. Each episode row carries episodeTitle, pubDate, duration, audioUrl, episodeUrl and the feed's own episodeGuid.
  • GUID-based new-episode detection. newEpisodesOnly emits an episode only when its GUID was not seen in a previous run — so a re-published or re-dated episode does not read as new, and a new one does.
  • Conditional requests. Feeds are fetched conditionally, so an unchanged feed transfers almost nothing between runs.
  • Bounded on purpose. maxEpisodes caps the most recent N episodes per show. There is no crawl-the-whole-archive mode.

How it works

  1. You supply podcast IDs (recommended) or search terms, plus a storefront.
  2. Search terms are resolved to shows at no more than one request per second, because /search* is disallowed by Apple's robots.txt; podcast IDs go straight through the allowed /lookup path.
  3. Each resolved show is emitted as a row with recordType: "show", carrying its metadata and canonical feedUrl.
  4. If fetchEpisodes is on, the Actor follows each feedUrl and parses the show's own RSS.
  5. The most recent maxEpisodes entries per show become rows with recordType: "episode".
  6. If newEpisodesOnly is on, an episode is emitted only when its GUID is absent from the previous run's set — and that set is then updated.

The first run with newEpisodesOnly has no baseline set of GUIDs, so it emits everything and logs that it did. From the second run on it emits only genuinely unseen episodes.

Input

At least one of podcastIds or searchTerms must be non-empty. Episode rows appear only when fetchEpisodes is on.

Input fields

FieldTypeDefaultWhat it does
searchTermsarray["true crime"] (prefilled)Show names, topics or publishers. Discovery path. Note: itunes.apple.com/robots.txt disallows /search*, so this path is rate-limited to 1 request/second and logs a notice. For a fixed watchlist, prefer Podcast IDs.
podcastIdsarray[]Apple podcast collection IDs, e.g. 1200361736 (The Daily). Uses the robots-allowed /lookup path. This is the recommended input for scheduled monitoring — it is both cheaper and cleaner.
countrystring"us"ISO-2 storefront code.
limitinteger25Max shows returned per search term. Ignored for Podcast ID lookups.
fetchEpisodesbooleanfalseFollow each show's public RSS feed and emit episode rows. Uses conditional requests, so unchanged feeds transfer almost nothing.
maxEpisodesinteger10Most recent N episodes per show. Bounded on purpose — there is no crawl-the-whole-archive mode.
newEpisodesOnlybooleanfalseEmit only episodes whose GUID was not seen in a previous run. Requires 'Fetch episodes'. The first run has no baseline, so it emits everything and logs that it did.
maxConcurrencyinteger5Concurrent requests to Apple and to RSS hosts. The search path is separately capped at 1 request/second regardless of this value.

Example input

One real Apple podcast collection ID — 1200361736 is The Daily — with episode fetching on and the ten most recent episodes kept.

{
"podcastIds": [
"1200361736"
],
"fetchEpisodes": true,
"maxEpisodes": 10,
"newEpisodesOnly": false
}

Output

Two row shapes share the dataset and are told apart by recordType. The show record below is a real row from a real run of this Actor, copied unedited.

Example output

{
"recordType": "show",
"podcastId": 1200361736,
"title": "The Daily",
"artist": "The New York Times",
"description": null,
"feedUrl": "https://feeds.simplecast.com/Sl5CSM3S",
"websiteUrl": "https://podcasts.apple.com/us/podcast/the-daily/id1200361736?uo=4",
"artworkUrl": "https://is1-ssl.mzstatic.com/image/thumb/Podcasts221/v4/ab/64/66/ab6466a9-9a7d-e20e-7a3d-bc5be37d29ce/mza_15084852813176276273.jpg/600x600bb.jpg",
"genres": [
"Daily News",
"Podcasts",
"News"
],
"episodeCount": 2697,
"contentRating": "Clean",
"releaseDate": "2026-08-21T09:52:00Z",
"country": "us",
"scrapedAt": "2026-08-22T07:33:54.604Z",
"billed": false
}

Output fields

Every field below is taken from that same real record. Values are truncated for width, never invented.

FieldTypeValue from a real run
recordTypestringshow
podcastIdnumber1200361736
titlestringThe Daily
artiststringThe New York Times
descriptionnullnull
feedUrlstringhttps://feeds.simplecast.com/Sl5CSM3S
websiteUrlstringhttps://podcasts.apple.com/us/podcast/the-daily/id1200361736?uo…
artworkUrlstringhttps://is1-ssl.mzstatic.com/image/thumb/Podcasts221/v4/ab/64/6…
genresarray["Daily News","Podcasts","News"]
episodeCountnumber2697
contentRatingstringClean
releaseDatestring2026-08-21T09:52:00Z
countrystringus
scrapedAtstring2026-08-22T07:33:54.604Z
billedbooleanfalse

Episode rows carry a different set of 12 fields, also from a real run:

{
"recordType": "episode",
"podcastId": 1200361736,
"podcastTitle": "The Daily",
"episodeGuid": "<the feed's own GUID for this episode>",
"episodeTitle": "<episode title>",
"description": "<episode description>",
"pubDate": "<RFC-822 publication date from the feed>",
"duration": "<duration as the feed states it>",
"audioUrl": "<direct link to the audio enclosure>",
"episodeUrl": "<the episode's own page, where the feed gives one>",
"isNew": true,
"scrapedAt": "<ISO timestamp of this run>"
}

The field names and types above are the real ones; the values are described rather than quoted, because an episode row is a moving target and a stale quote would read as a promise about a specific episode.

Pricing

Pay-per-event, split so that monitoring is cheap and discovery is what costs. Platform compute is not billed on top.

EventPriceCharged when
Podcast show$0.02One resolved show plus its feed. Charged only the first time this Actor resolves it for you - repeat monitoring runs re-read it free.
Actor start$0.00001Starting a run is charged at the platform minimum of $0.00001 - effectively free. You pay for what the run actually delivers.
Episode$0.0032One episode row from a resolved feed.
New episode$0.0037Fires in newEpisodesOnly mode for a genuinely unseen episode GUID. The alert, not the haystack.

What a run actually costs

Worked from the prices in the table above:

  • Four shows, resolved once. 4 shows x $0.02 = $0.08, one time.
  • The same four shows, watched daily with newEpisodesOnly. A show is charged the first time this Actor resolves it for you; repeat monitoring runs re-read it free. On a day when one of the four publishes, you pay $0.0037 for that new episode. A quiet day costs the $0.00001 run start.
  • A full episode pull. Ten episodes from one show: 10 x $0.0032 = $0.032.

The split is the point: you pay real money to discover a show and almost nothing to keep watching it.

FAQ

Do I need an Apple account or an API key?

No. The Actor calls Apple's public iTunes Lookup and Search endpoints, and then each show's own public RSS feed. There is no account, no key and no cookie in the path.

Why does Apple's directory not give me episodes?

Because it does not carry them. Apple's lookup returns show-level metadata and the canonical feed URL; the episodes live in the show's own RSS. That is why this Actor resolves the feed and then reads it.

What exactly counts as a "new" episode?

An episode whose GUID was not present in the previous run. GUIDs come from the feed itself, so an episode that is re-dated or re-titled does not read as new, and a genuinely new one does even if it is back-dated.

Why should I prefer podcast IDs over search terms?

Two reasons. itunes.apple.com/robots.txt disallows /search*, so the search path is rate-limited to one request per second; and a search result set changes between runs, which makes it a bad basis for monitoring. Resolve once, then watch the IDs.

Can I pull a show's entire back catalogue?

No. maxEpisodes caps at 100 most-recent episodes per show and there is no whole-archive mode. This is a monitor, not an archiver.

Does it download the audio?

No. Episode rows carry audioUrl, the direct link to the enclosure the feed publishes. The bytes stay where the publisher put them.

What happens if a feed is down or malformed?

The show row is still emitted with its metadata; the episode rows for that show are simply absent, and the log says why. One broken feed does not fail the run.

Limits and error handling

  • limit caps shows per search term at 200; it is ignored for podcast ID lookups.
  • maxEpisodes caps episodes per show at 100. There is no unbounded archive mode.
  • maxConcurrency is capped at 20 and defaults to 5, and applies to both Apple and RSS hosts. The search path ignores it and stays at one request per second.
  • Feeds are fetched conditionally, so an unchanged feed costs almost no transfer on a repeat run.
  • newEpisodesOnly requires fetchEpisodes; without episodes there is nothing to call new.

Integrations and API

Everything below works on any Apify account, including the free tier.

Run it from the Apify API

Start a run and wait for the dataset in one call. Replace <YOUR_TOKEN> with your own Apify API token.

curl -X POST "https://api.apify.com/v2/acts/praise-most-high~podcast-directory-monitor/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-d '{"podcastIds":["1200361736"],"fetchEpisodes":true,"maxEpisodes":10,"newEpisodesOnly":false}'

Use it from JavaScript or Python

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: '<YOUR_TOKEN>' });
const run = await client.actor('praise-most-high/podcast-directory-monitor').call({"podcastIds":["1200361736"],"fetchEpisodes":true,"maxEpisodes":10,"newEpisodesOnly":false});
const { items } = await client.dataset(run.defaultDatasetId).listItems();

Schedules, webhooks and integrations

Run it on a schedule — hourly, daily, or a cron expression — and have the output pushed where you already work. Apify ships first-party integrations for Zapier, Make, n8n, Slack, Google Drive, GitHub and generic webhooks, and any run can fire a webhook on success or failure. The dataset is also readable directly as JSON, CSV, XLSX, XML or RSS from its own URL, so a spreadsheet or a BI tool can point straight at it.

Where the data comes from

Two public sources, read live on every run:

  • Apple's public iTunes Lookup and Search API — show metadata, artwork, genres, and the canonical RSS feed URL.
  • Each show's own public RSS feed — the episodes themselves, exactly as the publisher serves them.

robots.txt was checked live against itunes.apple.com: /lookup?id= is allowed and /search* is disallowed, so the search path is opt-in, rate-limited to one request per second regardless of maxConcurrency, and used only to turn a term into a podcast ID. No headless browser, no proxy rotation, no bypass of anything.

Unofficial. This Actor is not affiliated with, endorsed by, or sponsored by Apple Inc. "Apple", "Apple Podcasts" and "iTunes" are trademarks of Apple Inc., used here only to describe the public data source it reads.

No personal data. Show and episode metadata published by the podcasters themselves. No listener data, no reviews, no accounts.

Your obligations. Episode titles, descriptions, artwork and audio are the publisher's copyrighted work. audioUrl is a link to their file on their server — it is not a licence to rehost, redistribute or transcribe it.

Support and feedback

Found a bug, a wrong field, or a source that changed shape? Open an issue on the Issues tab of this Actor and it goes straight to the maintainer. Feature requests are welcome on the same tab. If a run failed, include the run ID — the log is what makes it fixable.