Consider a price change at the MLS at 10:00. The importer receives it at 10:04. The search index updates at 10:06, but a cached property page still shows the old price at 10:20. Calling the feed “six minutes behind” would hide the part users actually see. Keep a clock for each step.
Follow one record through the pipeline
Store the source organization and record key with the source modification time, receipt time, and first public display time. If the provider gives only some of those values, label the gaps. Clock skew and batch publication can make source-to-receipt lag approximate; receipt-to-display lag is usually under your control.
A useful incident view shows the last successful request, oldest unprocessed update, index queue age, cache age, and media errors for each source. Keep the raw source record available to the support team under the applicable access rules. When a customer reports a stale photo, they should be able to find the incoming media record and the public version without matching on an address that might have changed.
AnyProp exposes ModificationTimestamp and PhotosChangeTimestamp as filters on the Property resource. These give a polling client a way to request changed listing or photo records. Log when your application receives and displays each change to see where the remaining delay occurs.
The same reference documents PropertyChange, an expansion containing old and new field values with modification timestamps. When investigating an unexpected price, compare that history with your import log and cached page. It gives the investigation a record to follow; a successful request count alone would not explain what the shopper saw.
Resume after an interruption
For a polling feed, save a checkpoint only after every record in the completed batch is stored. Page through results using the method the provider documents. On restart, repeat the last safe range and make the write idempotent: the same source key updates the same local record. Test this by stopping an import halfway through a multi-page result and running it again.
RESO’s EntityEvent specification describes another approach. Each event carries an increasing sequence, a resource name, and a record key. A consumer can resume after its last committed sequence and fetch the current record. RESO also defines an optional webhook push mechanism. Ask the provider which mechanism its feed actually exposes and how far back it can replay changes.
Do not assume that a gap in event numbers means lost listings. The EntityEvent specification permits producers to limit events to records a consumer may see. The test is whether a restart catches up to the current permitted state.
Handle records that leave the feed
A withdrawn listing, an expired listing, and a record removed from a particular licensed dataset may look similar in a public search. The source’s status and visibility rules determine what the product should do. A query returning no record is not enough evidence to invent a status.
EntityEvent explicitly covers a record that becomes unavailable to a consumer: the event can still name the key, while a fetch of the record returns nothing visible. Use that key to remove the public copy and its cached media as required. Keep an internal audit record of the action and timestamp, subject to the agreement, so support can explain why the page disappeared.
Run a periodic reconciliation against a complete, successful snapshot of the same authorized scope. Compare its keys with the records you previously stored to find candidates for removal. An incomplete page or failed request must not be treated as an empty dataset. Test the public index, saved-search alerts, and cached detail pages after a removal. An old search card may remain visible even after the database has been corrected.
Set a promise you can measure
If you need help investigating a delay in an AnyProp integration, send support the source, record key, relevant timestamps, and the observed result. Leave credentials out of the report. Those details let the investigation follow the same record from the feed to your application.
Report source-to-receipt and receipt-to-display delays separately. Use observed source schedules to set alerts; one market may publish in batches while another updates more often. A useful service promise names the visible screen and the measured interval, such as the time from receipt of a source update to the refreshed property page. It can then be checked against a real record rather than inferred from a healthy API response.
