Your MLS approved your Web API access and sent the docs. We turn that feed into listings, solds, agents and map search inside the site you already run, on WordPress, Laravel or custom code.
POST /token client_credentialsGET /$metadataGET /Property?$top=1000@odata.nextLink$filter=ModificationTimestamp gt {last}Credentials are the easy part. The work is the sync: paging through the whole feed, picking up only what changed, removing what went off market, and keeping photos, rosters and disclaimers right. That is what we build.
The RESO Web API is the standard the real estate industry uses to move listing data. It is published by RESO, the Real Estate Standards Organization, and built on OData version 4, a common standard for REST APIs over HTTP.
It works with the RESO Data Dictionary, which names the resources, fields and lookups: Property, Member, Office, Media and more, with over 1,700 fields and 3,100 lookups. Version 2.0 is the latest ratified release, and 2.1 is in draft.
RESO certifies MLSs, brokers and vendors on Web API Core 2.0.0 and Data Dictionary 2.0, and publishes a list of certified organizations.
When your MLS serves the Web API itself, you ask the MLS. RESO points brokers to their local MLS and its software provider for credentials.
Contact the MLS data or technology team and ask whether it serves the RESO Web API directly or through a vendor platform.
Pick the use that fits your site, where your MLS offers it: IDX for public listing display, VOW for signed in visitors, or back office for internal use.
The MLS sends its data licence agreement. It sets which fields, statuses and display rules apply, and any fee.
The MLS or its vendor issues OAuth client credentials or a bearer token, plus the endpoint URL.
The $metadata document shows the fields and lookups your licence includes. The sync is checked against it before your pages switch over.
Every certified feed shares the same core. What differs is the local fields and limits each MLS adds.
01Property for listings, Member and Office for rosters, Media for photos, and often OpenHouse. Names and core fields follow the Data Dictionary.
02GET $metadata returns an XML description of every resource, field and lookup on the feed. It is the first thing to read, since local fields differ by MLS.
03Standard OData options: $filter, $select, $top, $orderby and $expand. How far each one goes, such as the largest $top, is set by the MLS or its vendor.
04Large results come back a page at a time, with @odata.nextLink pointing to the next one.
05RESO describes replication as a full pull first, then requests for recent changes. Changes are found with a filter on ModificationTimestamp, tracking the last value seen.
06A changes query shows what changed, not what left. A purge that compares listing keys against your copy takes care of that.
Things that only show up once a feed has run for a few months. We learned them on a multi MLS platform we built and ran from 2018 to 2025.
Two certified feeds still differ in local fields, lookups and status values. Each MLS gets its own small filter class on top of the shared parser.
Large pulls come back a page at a time. We follow @odata.nextLink to the end and record where the run stopped.
A daily purge removes what left the feed. If the feed returns too few IDs, the purge is skipped and we get an alert.
IDX opt out flags and per listing address hiding are honoured, and each board's disclaimer shows the last updated time.
The credentials and token live in server config, not in plugin settings that editors can see. The sync runs from a server cron job and fills its own tables, so the theme reads listings without calling the MLS on each page view. Local fields are mapped once, in the sync.
Each MLS gets a config entry and a small filter class on top of a shared parser. Scheduled queued jobs run the changes pull, the weekly full re-sync and the daily purge. Models read the listing tables, and map search runs on a search index.
Any stack that can call an OAuth endpoint and run a schedule will do. Because the fields follow the Data Dictionary, adding a second MLS later reuses most of the mapping, and only the local fields and display rules need new code.
Your listings never go blank. The new sync runs beside whatever feeds the site today, and we only switch when the two match.
We check your MLS access, your platform and what the site needs to show.
The new sync fills its own tables while your current pages carry on.
Counts, statuses, photos and rosters checked against the MLS.
Pages read from the new sync. Whatever fed them before is switched off.
Some MLSs serve the Web API themselves, others through a platform like Trestle, Bridge, MLS Grid or Spark, and many offer more than one route. A direct feed has fewer layers and one relationship. A platform adds its own fees, but gives you one account across several MLSs.
For one MLS, a direct feed keeps things simple. For several, a platform can cut the work on contracts and credentials. Either way the data follows the same standard, so the sync code changes little.
Your site's address, what it runs on, and which MLS or feed you have access to.
Access, fields, photos, rosters, and how your platform stores listings.
What syncs, how often, what shows where, and a fixed price for the build.
If you go ahead, the $499 comes off the integration.
We are an independent developer. We are not affiliated with, or certified by, any MLS or data provider named on this page.
Send the site's address and the feed you have access to. The audit gives you a written plan and a fixed quote.