Podcast New Episode Monitor

Watches any podcast published in Apple Podcasts and tells you the moment a new episode goes live — title, description, publish date, duration, direct link. No login, no API key, no scraping: this actor talks only to Apple's own free, unauthenticated itunes.apple.com Lookup API and the podcast's own public RSS feed (the same feed every podcast app already reads).

How it works

1. You give each watch a podcastId — the numeric Apple/iTunes id from the podcast's own podcasts.apple.com URL (e.g. .../id1200361736 → 1200361736).
2. Every run, the actor asks Apple's Lookup API for that podcast's current RSS feedUrl (never cached long-term — if the show switches hosting providers, the actor follows automatically) and fetches the feed.
3. Episode identity is the feed's own <guid> (falling back to <link> if a <guid> is missing). The first run for a watch establishes a baseline silently — no episode is billed as "new" just because it's the first time the actor has seen the show. Every run after that reports only episodes that genuinely appeared since the previous check.

Pricing (pay-per-event)

• feed-checked — charged once per watch per run, whether or not anything changed. This is the cost of doing the check.
• new-episode-detected — charged once per genuinely new episode delivered.

Input

{
  "monitorId": "my-podcast-monitor",
  "watches": [
    { "watchId": "the-daily", "podcastId": "1200361736" }
  ],
  "webhookUrl": "https://your-endpoint.example.com/hook"
}

watchId is your own label for the watch (used in output rows). podcastId is Apple's numeric collection id. webhookUrl is optional — HTTPS only — and receives a JSON summary of each run.

Guarantees

• At-most-once billing under crash/retry — never charged twice. An atomic claim on Apify's Request Queue (the platform's only atomic primitive) is acquired before any dataset write or charge, and is granted exactly once for the lifetime of the monitor. If a run is interrupted right after winning that claim, the event can be lost (never delivered/billed) — but it will never be billed a second time. A durable per-monitor ledger records each episode's progress for reporting and troubleshooting.
• Single-flight. Two overlapping runs of the same monitor can't double-process — a lease, acquired before any state is read, blocks the second run cleanly.
• Durable state. Each monitor's seen-episode history, ledgers and delivered rows live in a named per-monitor store that persists across every scheduled run, not just within one run.

Built by OmniCoder (https://t.me/OmniCoder).