A listing that falls out of the first ten search results and later returns is not necessarily a new property. A monitor that remembers only its latest window can repeatedly announce and bill that same identity. A rolling-window watch needs durable seen history as well as an honest statement of what it observed.
Re New Listing Alert watches a named portal search. Its Krisha adapter uses an explicit newest-first window and preserves a union of seen listing identities. The observation is bounded: newly entering this watch is not the same claim as newly published anywhere in the market.
Keep the watch definition stable
This is the installed public example for Almaty apartment sales. filter.max_items controls the source sample here, while the outer max_items caps new-listing delivery. The JSON illustrates the request; it is not a fresh inventory of available apartments.
{
"portal": "krisha-kz",
"filter": {
"queries": [
"sale:apartment:almaty"
],
"max_items": 10,
"max_pages": 1
},
"watch_name": "almaty-apartments-example",
"max_items": 10
}
Store portal, filter, watch_name and collection limits together in your configuration. If you change the business meaning of the search, use a deliberate new watch or document the transition. Reusing a familiar display name for a materially different search makes historical new-listing counts difficult to interpret.
Treat first observation as a baseline
The first accepted check establishes which listing identities are already known. A baseline-created row explains that state; it is not a batch of previously unseen opportunities relative to a nonexistent earlier observation. A baseline snapshot can itself be a paid result, so inspect the current listing and spending limit before starting a watch.
Later complete observations can deliver identities absent from the durable seen set. For Krisha, the declared add_date-desc ordering and clean parsing of the window support rolling-ranked-window status. They do not prove a full-market crawl. Other portals have their own completeness requirements; do not transfer Krisha's window acceptance rule to every adapter.
Preserve identities outside the current window
The durable union matters when listing A is present, disappears behind newer results and later returns. If A was already delivered or included in the baseline, its return is not a first observation. A store containing only the current ten IDs would lose that fact and create repeated alerts.
Keep your destination's own delivered identity record as an additional import guard. A run outcome and a successful downstream import are different boundaries. If your consumer stops after receiving several rows, replay the saved Dataset into your destination with idempotent destination keys rather than automatically recollecting the whole source window.
Keep partial checks from advancing history
Partial snapshots, errors and quiet checks do not become new paid listing results. An unconfirmed charge or broken contract must not advance the affected baseline. Inspect partialReason, snapshotMode and observed counts instead of relying on a single found flag.
For a useful fixture, arrange windows A/B, B/C and A/C and verify that A's return is not new. Add an incomplete middle observation and confirm that it does not silently rewrite history. The real platform acceptance must also inspect named storage and charge counters; a pure local set comparison cannot establish those effects. In the reporting interface, label the metric as first observed by this watch and show its configured window alongside the alert count.
Price and verification scope
FREE-tier event prices read on 24 October 2026 are $0.005 for apify-actor-start and $0.01 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.
This article is pinned to public latest build 0.1.8 (0dxwpu6Gzsqxs8zpt) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.
Inspect the Actor's current contract and pricing.
AI-assisted writing. Source contracts and verification limits are documented above.
Top comments (0)