A listing can be accurate at the source and still look stale on a brokerage website.
At 9:07 a.m., an agent marks a home Pending in the MLS; one portal reflects it minutes later, while another still shows it as active at lunch. That gap does not automatically mean either site is broken.
A property record often passes through several systems: the MLS database, a data feed or API, an IDX provider’s ingestion queue, its searchable listing index, and the brokerage site’s own cache or CDN. Each layer may refresh on a different schedule. Some changes—price, status, open-house time, photo removal—can also be handled differently: a feed may deliver the new value promptly, yet the receiving platform may defer reindexing or retain a cached search result. Display rules add another wrinkle. A listing can be withheld, delayed, or shown with limited fields under MLS policy, even while the underlying record has changed.
- MLS export batches may run hourly or overnight.
- Search indexes can update separately from listing-detail pages.
- CDN and browser caching can preserve an older page after the data changes.
What Actually Changes in an IDX Feed
- New listing records
A newly published MLS record is usually delivered as an incremental add event. It may appear quickly, but search indexes, map tiles, and local caches can introduce a separate display delay. This is central to understanding what IDX means for a real estate site.
- Field edits
Price, remarks, beds, baths, open-house times, agent details, and location corrections are amendments to an existing record. Providers commonly poll or receive these deltas more often than they run a complete database rebuild.
- Status changes
Active, pending, contingent, sold, canceled, expired, and withdrawn transitions are edits with unusually high visibility. MLS rules and feed mappings may determine whether a status is shown immediately, delayed, or suppressed on public IDX pages.
- Photos and attachments
Images, virtual tours, and documents can arrive after the listing record, or update through a separate media endpoint. A current price alongside older photos does not necessarily indicate that the primary listing feed is stale.
- Removals and full synchronization
A removal may be sent as a delete or status event, yet a full synchronization reconciles every permitted record against the MLS source. Delta delivery is frequent and lightweight; full syncs are slower, scheduled less often, and catch missed changes or records no longer eligible for display.
How quickly listings can realistically refresh
A credible IDX refresh range runs from near real time—roughly 1 to 15 minutes—to several hours. Some implementations receive incremental changes through a webhook, streaming service, or frequent RESO Web API polling. Others collect scheduled batch files, so a new price or pending status may not appear until the next import cycle.
“Real-time IDX” is therefore a description of an available delivery pattern, not a universal outcome. The practical ceiling is set by the slowest approved handoff:
- MLS publication rules: An MLS may limit how often vendors can query data, delay certain statuses, or require refreshes within a stated maximum window.
- Provider processing: The IDX vendor must retrieve, normalize, validate, and index the change before the site can search it.
- Site caching: CDN, application, and search-index caches can add minutes after the feed itself has updated.
- Media delivery: Photos and virtual-tour links commonly lag record updates because assets are fetched and processed separately.
A well-run site should state a specific timestamp such as “data last refreshed at 10:42 a.m.” and distinguish it from the listing’s MLS modification time. That makes a two-hour batch cadence visible rather than implying instantaneous synchronization.
From an MLS edit to the listing page
- The MLS accepts and publishes the change
An agent saves a price, status, description, or photo change in the MLS. The record may first pass field validation, office or broker rules, and an MLS publishing cycle before it becomes available through the approved IDX feed or API.
- The IDX provider ingests and normalizes it
A polling job, webhook, or scheduled feed fetch detects the revision. The platform then maps MLS-specific fields, applies display and compliance rules, deduplicates records, and places large batches in processing queues.
- Search and detail data are indexed separately
The canonical record can arrive before it is searchable. Search indexes must rebuild facets such as price, beds, status, map coordinates, and sort values; a listing-detail service may read from a different store with its own replication lag.
- Photos take a parallel route
New media commonly has the longest tail. Image URLs are fetched or copied, virus-scanned, resized into multiple breakpoints, watermarked where required, and distributed to image storage or a CDN. The listing can show its new price while retaining an old hero photo—or a temporary placeholder.
- Caches decide what a visitor sees
The application may cache rendered pages, API responses, search results, and map tiles. A CDN can continue serving an earlier version until its time-to-live expires or a purge reaches every edge location; browser caching can add one final delay.
A timestamp on the page may describe the MLS record’s last modification, not the moment every index, image variant, and cache was refreshed.
A single MLS revision can produce several independent events: record ingestion, search reindexing, media processing, and cache invalidation. That is why a status change may appear before a photo, or a detail page may update before the listing moves in search results.
Why feed technology changes the update pattern
RETS was designed around broker and vendor data retrieval, not instantaneous public-site notification. Many RETS integrations therefore run scheduled queries for modified records, often with a later full download to catch missed changes. File-based exports—such as CSV, XML, or nightly media packages—are more explicitly batch-oriented: the receiving IDX cannot display a change until the next file is produced, transferred, and processed.
API feeds can request only records changed since a timestamp, reducing the work needed per run. Event-driven delivery goes further: a provider may push a notification when a listing, status, or photo changes, allowing the IDX platform to fetch and publish the affected record quickly. Neither approach guarantees an immediate page update; validation, image processing, search indexing, and cache expiry still apply.
Authority and display rights are separate
The MLS is the system of record: its database and rules determine which property data exists and which changes are official. IDX is the licensed mechanism for publicly displaying a permitted subset of that data. Understanding how MLS authority differs from IDX display explains why a technically capable feed may still omit fields, suppress withdrawn records, delay status visibility, or require specific attribution.
MLS policy sets the ceiling on freshness and content. It may prescribe refresh intervals, prohibit certain data uses, impose display rules, or make some updates available only through approved vendors. An IDX provider can optimize its pipeline, but it cannot legitimately publish data that the MLS has not released or authorized.
Why an IDX page may omit or remove a listing
An IDX site is not necessarily entitled to display every field stored in the MLS. Each MLS defines its IDX data set and display rules, often at field level. Agent-only remarks, showing instructions, seller contact details, compensation information, and certain documents may be available inside the MLS yet deliberately excluded from public feeds.
Listing status can trigger equally deliberate changes. A record may disappear from search when it becomes withdrawn, canceled, expired, sold, or temporarily off market—even if it remains searchable to MLS participants. Some markets permit a pending listing to stay visible but restrict its address, days-on-market value, or price-history display. Others require prompt removal after a seller’s opt-out or an IDX suppression flag.
Signs of a policy outcome
A compliance-driven difference usually has a recognizable pattern:
- The field is absent across all IDX sites, while MLS members can see it.
- The listing vanishes exactly when its status changes.
- Search results omit the property, but a direct MLS record still exists for authorized users.
- A brokerage’s own listing is shown differently because its permissions differ from those of other participants.
A true sync issue is more likely when a permitted field is stale or inconsistent only on one site after the normal refresh window. Comparing the public IDX display, the MLS status, and the local MLS’s published IDX rules separates a missing feed update from an intentional restriction.
Fresh feed, stale visitor view
An IDX provider can receive a status change within minutes and still show the old result on the public site. Ingestion freshness answers when the provider obtained the MLS update; it does not prove that the search index, detail-page payload, or rendered page has been replaced.
Each layer has its own clock
A new record may wait for indexing before it appears in filters or map results. A price or status edit may reach the database first, while a prebuilt listing page, image service, or search cache continues to serve its earlier version. XML sitemaps commonly refresh on a separate schedule, and their timestamps describe URL discovery—not the live data a visitor receives.
Browser caching and a CDN add another gap. A CDN configured with a 15-minute TTL can serve an old “Active” page even after the origin is correct; a visitor’s browser may extend that delay. These distinctions also matter when evaluating whether IDX pages affect SEO: Google may recrawl long after the site itself is current, and it can retain an older indexed snippet longer still.
The practical test is an end-to-end one: record the MLS modification time, then check the public search result and detail page from a cache-bypassing session or multiple regions. For fast-moving status fields—Active, Pending, Sold, Withdrawn—monitor the visible page, structured data, and API response separately. A feed-level timestamp alone can conceal the delay that matters most: what a prospective buyer sees.
Track MLS edit time against the first correct public result. For status changes, alert on search, detail-page, and cached-response lag independently.
Questions That Reveal Actual Listing Latency
- A clock with defined endpoints
Ask for typical and maximum latency for each MLS, measured from the MLS save time to an uncached public listing page. Status changes, price edits, removals, and new listings should be timed separately.
Look forMLS-specific, end-to-end targets with clear start and finish timestamps.AvoidA blanket “real-time” promise without a measurement method. - Proof from a controlled edit
A credible vendor can show a recent test edit and timestamps for feed receipt, processing, indexing, cache invalidation, and public display. Confirm the timezone and whether the final page was served from a CDN edge.
Look forTimestamped evidence through every handoff.AvoidDashboard screenshots showing only when the feed arrived. - Retries and reconciliation
Ask what happens when an MLS endpoint, parser, or queue fails: retry intervals, alerting, dead-letter handling, and full reconciliation cadence. The answer should explain how silent misses are detected and corrected.
Look forBounded retries, monitoring, and scheduled repair runs.Avoid“It retries automatically” with no limits or escalation path. - Photos and cache purges
Media often follows a slower pipeline than listing fields. Confirm timing for additions, replacements, deletions, image ordering, and CDN purge propagation.
Look forSeparate media SLA and purge behavior by cache layer.AvoidTreating photo freshness as identical to text updates.
Correct a suspect listing with evidence
When a listing appears inaccurate, first identify the authoritative source: the MLS record, an authorized broker feed, or the listing agent’s confirmed update. Compare the listing ID, status, field values, photos, and timestamps—not just the public page. Guidance for wrong property information is especially useful when the error could affect a buyer’s decision.
Document the mismatch
Capture the page URL and screenshots, noting the date, time zone, listing ID, and the exact field or image at issue. Record where the correct version was observed. This separates a source-data error from an IDX indexing or cache delay.
Escalate with those details to the party able to act: the listing agent or broker for an MLS correction, and the site’s IDX support contact for delivery or display issues. Ask for the record’s status at each handoff—MLS, feed receipt, index, and page cache. A meaningful freshness standard is not a vendor-wide promise; it is documented end-to-end behavior for that MLS and that site.
Treat the listing path as evidence
- A precise listing ID, timestamps, and screenshots turn a vague complaint into an actionable case.
- Source correction and site propagation are separate fixes, often owned by different parties.
The reliable test is whether a specific local MLS change can be traced through the feed, index, and visitor-facing page—not whether an IDX provider advertises a generic update interval.
