MLS Grid serves several MLSs through one RESO Web API. We sync it into your WordPress, Laravel or custom site and keep it current every 2 to 3 hours.
Authorization: Bearer {token}$filter=MlgCanView eq true$expand=MediaModificationTimestamp gt {last}MlgCanView eq falseMLS Grid expects every query to respect its visibility flag and every removed listing to come down. Miss that and you are showing data you shouldn't. MLS Grid was one of the feeds on a multi MLS platform we built and ran from 2018 to 2025.
MLS Grid is a data distribution service shared by its participating MLSs. Each MLS hands out one feed under one set of rules, and brokers and vendors sign one standard licence that covers IDX, VOW and third party vendor use.
The API follows the RESO Web API, and the current version is 2.0. It is built for replication only. MLS Grid states that it does not support on demand queries, so you copy the data to your own database and search it there.
That is the main difference from the other platforms. Your site always reads its own copy, and you are expected to keep that copy in step with the feed, including removals and photo changes.
MLS Grid uses one standard licence for every participating MLS. Your MLS still has to approve you before a token is issued.
Sign up with MLS Grid. Brokers and vendors work under the same rules and the same licence.
Create a subscription for each MLS you need and choose the use, such as IDX or VOW.
Name the licensee on the subscription and sign the standard licence agreement.
The MLS reviews and approves the subscription. Nothing is issued until it does.
Once approved, the API token appears on the subscription's token tab. It is a long term token, so it is stored as a server secret.
MLS Grid's Web API 2.0 has firm rules. A sync that ignores them gets throttled or shows data it should not.
01Property, Member, Office, OpenHouse and Lookup. Media is not its own endpoint: it is expanded on Property, Member and Office, and Rooms and UnitTypes expand on Property.
02Every request must filter on OriginatingSystemName with a single value. Two MLSs mean two sets of requests.
03$top defaults to 500 and goes up to 5,000, or 1,000 when $expand is used. @odata.nextLink is followed until a response comes back without one.
04Pulls filter on ModificationTimestamp gt the last value seen. The first load uses MlgCanView eq true. After that, pulls leave the filter off so false values arrive, and those records are deleted. They stay in the feed as false for 7 days.
05You must keep your own copy of every photo. Media URLs are signed, expire after an hour and allow one download, so they cannot be stored or used on a page.
06Media, Rooms and UnitTypes carry no delete flag. Each update replaces them with whatever the parent record now returns.
07No more than 2 requests a second, 7,200 an hour, 40,000 a day and 4 GB of downloads an hour. Going higher needs MLS Grid's agreement in advance.
MLS Grid is strict about how its feed is consumed. These are the rules the sync follows, taken from the Grid's own documentation.
The sync filters on MlgCanView eq true for the first load only. After that the filter stays off, so records that flip to false still arrive and come off your site, which is what MLS Grid's own documentation asks for.
Photos come back with the listing through $expand=Media, ordered by Order, rather than through a separate call.
Some MLSs on the Grid add their own display requirements. Each one lives in its own filter class.
Large pulls come back a page at a time. We follow @odata.nextLink to the end and record where the run stopped.
Photos have to be downloaded and kept, so they go to object storage behind a CDN rather than the WordPress media library, which is not built for that volume. The token is a long term secret held in server config. The sync runs from a server cron job, paced to 2 requests a second.
A rate limited queue keeps all workers under 2 requests a second combined. Photo downloads run as their own jobs straight after each listing update, since the signed URL expires within the hour. One set of jobs per OriginatingSystemName keeps each MLS separate.
Whatever the stack, the site reads only its own database, because MLS Grid does not serve on demand queries. Map search, filters and listing pages all run on the local copy. The MlgCanView deletes and the photo replacement logic sit in the sync, not the front end.
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 Grid access, your platform and what the site needs to show.
It fills its own tables while your current listings stay up.
Counts, statuses, photos and rosters checked against the feed.
Pages read from the new sync. The old plugin or script is removed.
Some MLSs on MLS Grid also offer their data through other routes, and some do not. Where you have a choice, the listings follow the same RESO standard. The difference is in the licence terms, the fees, and the rules for photos and removals.
MLS Grid suits a broker covering several of its MLSs, since one licence and one token cover them all. It costs more in storage, because every photo is downloaded and kept, and it needs a sync that sticks to the request limits.
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.