Keeping MLS listings current: a replication checklist for real estate platforms

Keeping MLS listings current comes down to five jobs done on a schedule: one full initial download, frequent incremental pulls based on each record's modification timestamp, a regular purge of listings you are no longer allowed to show, media downloaded once and served from your own storage, and monitoring that tells you when any of it stops. Most "stale listing" complaints on real estate platforms trace back to one of these being skipped.

This is a working checklist for PropTech teams and brokerages that replicate MLS data into their own database. For the bigger picture of how listing data fits into a marketing platform, see Real estate marketing platform architecture.

Every MLS and feed provider has its own rules, so read your provider's documentation first. The examples below quote two public ones: MLS Grid's API documentation and Spark's RESO Web API replication guide.

1. Do the initial download once, and make it resumable

• Page through the full dataset using the @odata.nextLink the API returns. Spark calls this "the recommended method for replicating data" and warns that paging with $skip can duplicate records when new listings shift results between requests.
• Record the last ModificationTimestamp you received. MLS Grid suggests adding it to the query if an import fails, so you do not download everything again.
• Ask only for the fields you use. Spark recommends $select to limit fields and asks you to expand custom fields only when you need them, because they significantly increase payload size.

2. Pull changes on a timestamp window, not a full reload

• After the first load, request only records whose ModificationTimestamp is newer than the latest one you hold. MLS Grid notes this "avoids repulling the same data over and over again."
• Use a lower and an upper bound for each window. Spark says to "always use two timestamps to specify a start and end of your polling window" to avoid errors caused by caching, and to start the next window from the most recent timestamp of the previous request.
• Check your provider's polling guidance. Spark recommends polling "no more than once every 10 minutes but at least once every hour."
• Make the write idempotent: an update replaces your local copy of that listing, so running the same window twice does no harm.

3. Purge listings you can no longer show

Listings leave the feed when their status changes, and a platform that only ever adds and updates will keep showing them. This is the step most often missing.

• MLS Grid marks these with an MlgCanView field: when it is false, remove the record from your data store. Those records drop out of the feed entirely after 7 days, so a weekly job is too slow.
• Spark recommends a purge process run "no less than once daily": request only listing keys, compare them with your local data, and purge any records that do not match. It warns that skipping this "can result in continuing to display listings that are no longer active or eligible for display."

4. Download media once and serve it yourself

• Track the photo change timestamps your provider exposes (for example PhotosChangeTimestamp) and re-fetch media only when they change. MLS Grid puts it plainly: "There is NEVER a reason to download the same media more than once."
• Do not hotlink. MLS Grid's media URLs are signed, single-use and expire one hour after they are generated, and it asks you to use them only to download a local copy.
• Run media downloads as background jobs, separate from listing data, so a slow image never holds up a price or status change.

5. Respect limits and watch the sync

• Know your page and request limits. MLS Grid allows up to 5,000 records per request (1,000 with $expand) and returns a 429 error for repeated media downloads within the hour.
• Alert when the newest ModificationTimestamp you hold stops moving during business hours. That single number tells you whether the sync is alive.
• Log every failed page and retry it, instead of letting a job fail silently. See Why automations fail silently and create duplicate records.
• Compare your active listing count with the feed's count on a schedule; a growing gap means the purge or the update job is broken.

The checklist

• Initial download pages with @odata.nextLink and can resume from the last timestamp.
• Incremental pulls use a two-timestamp window on your provider's schedule.
• Updates replace the local record; re-running a window is safe.
• A purge runs at least daily and removes listings you can no longer display.
• Media is downloaded once per change, stored locally, never hotlinked.
• Requests stay inside your provider's limits.
• An alert fires when the newest timestamp stops moving.

Not sure which of these your platform does today? Bring it to a Systems Discovery Call and we will check it with you.

How we work on Zentap

We work long-term on Zentap, a real estate marketing platform serving 20,000+ agents. Zentap enables real estate professionals to manage, market, and distribute property listings from a centralized system. Our work covers Rails product engineering, MLS integrations, and automated marketing, keeping listing information aligned with current market data and the platform reliable at scale. The details are on our real estate software development page.

Common questions

How often should we sync MLS listings?

Follow your provider's rules. As one example, Spark recommends polling for updates no more than once every 10 minutes but at least once every hour, and running a purge at least once a day.

Why do sold or withdrawn listings still show on our site?

Usually because the sync only adds and updates records and never removes them. Add a daily purge that compares your listing keys with the feed and removes the ones that are gone.

Can we use the photo URLs from the feed directly?

Check your provider. MLS Grid's media URLs expire after an hour and are for downloading a local copy only, so the images need to live in your own storage.

Next step

If your listings drift from the MLS or your sync breaks without anyone noticing, book a Systems Discovery Call. It is 45 minutes on your platform, and you leave with a clear picture of what to fix first, whether you hire us or not.