RSS Change Monitor

Watch RSS and Atom feeds and get only what changed since the last run. Schedule it, point a webhook at it, and stop re-processing the same items every time.

Charged per feed successfully checked. A feed that fails to fetch or isn't a feed is reported with the error and never charged.

---

Why not just parse the feed?

Parsing RSS is a library call. What you actually want scheduled is "tell me what's new" — and that needs state carried between runs, which no parser gives you. This Actor keeps a fingerprint of every feed in a named key-value store, so consecutive runs can diff against it.

That state is the whole product, and getting the diff right is harder than it looks.

The four things naive change-detection gets wrong

1. Item identity. Many feeds re-stamp <link> with utm_* tracking parameters on every fetch, and some republish items with a fresh <guid>. Diff on the link, or on a hash of the whole item, and you'll get change alerts for items that never changed. We resolve identity in order: guid → id → link with tracking parameters stripped → title + date.

2. New versus edited. A corrected article isn't a new one. We keep a separate content fingerprint per item, so edits come back as updatedItems and genuinely new items as newItems. You decide which matters.

3. Items disappearing is not deletion. Feeds carry only the latest N entries, so items scroll off the bottom constantly. Reporting those as "removed" would be a lie by construction, so we don't report removals at all.

4. The first run. There's no previous state, so nothing has changed. Tools that report every existing item as new on run one flood your webhook the moment you schedule them. Our first run records a baseline, reports zero changes, and says so explicitly in the output.

Both formats. RSS (<item>, <pubDate>, <link>) and Atom (<entry>, <updated>, <link href>) are both handled. A monitor that only reads RSS silently misses half the web.

---

Input

{
  "feedUrls": [
    "https://news.ycombinator.com/rss",
    "https://example.com/blog/atom.xml"
  ],
  "stateStoreName": "my-watchlist"
}

Field	Type	Default	Notes
feedUrls	array	—	Feeds to watch
feedUrl	string	—	Watch a single feed
stateStoreName	string	rss-monitor-state	Where the baseline lives. Different names keep independent watchlists apart.
resetBaseline	boolean	false	Forget history and start fresh. That run reports no changes.
maxNewItemsPerFeed	integer	50	Caps output size on busy feeds. Counts stay exact.
maxFeeds	integer	25	Cap on feeds, and therefore on spend

Output

One record per feed, plus a SUMMARY:

{
  "feedUrl": "https://example.com/feed.xml",
  "ok": true,
  "feedTitle": "Example Blog",
  "format": "rss",
  "status": "changed",
  "isFirstRun": false,
  "itemsInFeed": 30,
  "newCount": 2,
  "updatedCount": 1,
  "newItems": [
    {
      "id": "https://example.com/post-42",
      "title": "The post that just went up",
      "link": "https://example.com/post-42",
      "published": "Sun, 27 Jul 2026 18:04:00 GMT",
      "author": "Jane Doe",
      "summary": "First 600 characters of the description…"
    }
  ],
  "updatedItems": [],
  "checkedAt": "2026-07-27T20:31:00.000Z"
}

status is baseline on the first run for a feed, then changed or unchanged.

Scheduling

Set an Apify schedule (hourly, daily, whatever suits) and attach a webhook on run success. Every run after the first tells you exactly what appeared or changed. Keep the same stateStoreName across runs — that's what makes the diff possible.

For agents and automation

• Capability: detect new and updated items across RSS/Atom feeds between scheduled runs
• Required input: feedUrl or feedUrls
• Returns: one record per feed plus a SUMMARY; newItems / updatedItems are the payload
• Stateful by design: the named key-value store persists between runs. Same store name = same watchlist.
• Bounded: maxFeeds caps the run and the spend
• Side effects: reads feeds, writes fingerprints to your own key-value store. Nothing external.
• Failure: a bad feed is returned as a record with ok: false and an error; the run continues and that feed is not charged.

Pricing

Pay per feed successfully checked. Failed fetches are free.

FAQ

How do I get notified when an RSS feed has new items? Schedule this actor (hourly or daily), attach a webhook on run success, and read newItems — every run after the first reports only what appeared since the previous one.

Why did the first run report zero changes? By design. With no previous state nothing has "changed"; the first run records a baseline and says so (status: "baseline") instead of flooding your webhook with every existing item — the classic failure of naive monitors.

How does it tell a new item from an edited one? Identity is resolved guid → id → tracking-stripped link → title+date, and a separate content fingerprint per item catches edits — so corrections come back in updatedItems and genuinely new posts in newItems.

Can I watch several unrelated feed lists? Yes — give each watchlist its own stateStoreName. Different store names keep fully independent baselines.

Does it work with Atom feeds? Yes — RSS (<item>) and Atom (<entry>) are both parsed; a monitor that only reads RSS silently misses half the web.

How do I reset the baseline? Run once with resetBaseline: true — history is forgotten, that run reports no changes, and monitoring continues fresh from there.

For AI agents

This Actor is built to be called by software, not just by people.

• Mount it directly as an MCP tool — no Store search, no ranking, just this one tool: https://mcp.apify.com/?actors=eliai/rss-change-monitor
• Or call it over HTTP and get the results in the same request: POST https://api.apify.com/v2/acts/eliai~rss-change-monitor/run-sync-get-dataset-items
• Pay with x402, without an Apify account. This Actor is whitelisted for agentic payments, so an agent holding USDC on Base can buy a prepaid token and spend it here. The minimum purchase is $1, the token balance is an absolute spending cap, and it expires 14 days after purchase.
• Costs are predictable before you call. Pricing is pay-per-event (see Pricing above), so an agent can budget a run in advance instead of discovering the bill afterwards.
• Send only the field you mean. If you pass the bulk field, it is used on its own; the single-value field is a fallback, never merged into your request. You are charged for the items you sent and nothing else.