A feed poll is an execution event. A new article or an edited feed item is a content event. Treating the two as interchangeable creates duplicate editorial tasks every time a schedule fires. A useful feed pipeline needs item identity, version identity and a deliberate place to store its comparison state.
RSS Feed Scraper and Monitor reads permitted RSS 2.0 and Atom 1.0 sources. Snapshot mode returns eligible items for the current check. Monitor mode compares item versions with a selected persistent store and returns new or edited versions. It does not download the articles linked from the feed.
Inspect a snapshot before monitoring
The installed prefill is a project-owned synthetic feed. That makes the first inspection independent of a publisher adding or removing live entries during your test. Start with snapshot mode and inspect the normalized item fields before introducing persistent state.
{
"feedUrls": [
"https://api.apify.com/v2/key-value-stores/b0cgFsJRqVv3XOZyG/records/feed.xml"
],
"mode": "snapshot",
"maxItemsPerFeed": 20
}
The input accepts one through ten feed URLs and one through one hundred items per feed. These bounds control the requested source projection. They do not promise a complete historical archive of everything the publisher has ever posted.
Keep source identity and version evidence
A feed entry can retain its identity while its title or summary changes. Preserve the returned stable item and content-version evidence rather than using the title alone as a key. A title is presentation data and can be edited without creating a new editorial work item.
Keep source publication dates as source values. The time your pipeline noticed an entry is separate from the time supplied by the feed. Backfilled entries and edited dates can otherwise make a dashboard imply that content was published at the moment a poll discovered it.
Give monitor state an owner
For monitor mode, select an existing persistent Apify store that the workflow is authorized to use. Record its identifier in the workflow configuration. Reusing the same state intentionally is different from starting with an empty store and expecting the monitor to remember a previous run.
Separate state for independently operated workflows unless shared suppression is the intended behavior. If two consumers use one state store without agreeing on that behavior, one can affect which changes the other receives. Document the state lifecycle alongside the source list and retention policy. Serialize monitor runs that share a store. The current contract retains a bounded history of ten thousand item versions; eviction can allow an old version to reappear. Delivery and the state checkpoint are not transactional, so a crash can also repeat a version. Keep a downstream deduplication key rather than assuming exactly-once delivery.
Handle unchanged and incomplete runs differently
A repeated monitor pass with no eligible changes can return a free no_changes result. That is useful evidence that the comparison found nothing new within the checked scope. A source error or a capped feed is a different outcome and should not be recorded as proof that nothing changed.
The summary text comes from the feed's description or Atom summary, normalized to plain text. It is not a full article download, an accuracy check or permission to republish the linked article. Keep the source link for a separate reading and editorial decision.
Build an editorial queue, not an automatic conclusion
Route complete new and edited items to a review table with their source and version evidence. Preserve operational notices in a separate view tied to the same run. Let the receiving workflow decide whether an edit needs another review or merely an update to an existing record.
Before scheduling frequent polls, compare the planned frequency with the source's actual publication pace. Repeated execution can incur start events even when there are no changed items. A well-designed monitor makes both the content outcome and the execution cost visible.
Cost and verification scope
The current FREE-tier result price is $0.0005 for the documented unit: One unique or changed RSS feed item with normalized fields. The listing also has a $0.005 start event, charged per GB of Actor memory with a minimum of one event. A free diagnostic row does not refund that start event. Discounted platform tiers have their own rates; inspect your applicable tier before estimating a batch. These are listing prices read on 21 October 2026, not a receipt or a claim about customer spending.
The contract for this draft was checked against installed build 0.1.3 (oRW0oJy8grfDMTbBA). The input above is an illustrative schema example, not a newly executed run. Current source responses and useful output still need inspection when you choose to run it. No new cloud build or run was made to prepare this article.
Open the Actor and inspect its input and pricing.
AI-assisted draft; publication requires independent technical review.
Top comments (0)