Bridge Interactive gives you a RESO Web API dataset for each approved MLS. We sync it into your WordPress, Laravel or custom site and keep it current every 2 to 3 hours.
server token per applicationGET /{dataset}/Property/replication$filter=BridgeModificationTimestamp gt {last}application-ratelimit-remainingMedia ordered by OrderBridge gives you the feed and the docs. The sync, the purge, the photos and the display rules are on you. Bridge was one of the feeds on a multi MLS platform we built and ran from 2018 to 2025.
Bridge Interactive is a real estate data platform owned by Zillow Group. MLSs use it to distribute their listing data, and developers apply through it for access to each MLS dataset they need.
Data is served through the RESO Web API, normalized to the RESO Data Dictionary and filtered by whatever restrictions the MLS has set. Bridge also runs its own Bridge Web API, and a virtual RETS API built to RETS 1.9 for consumers approved with replication.
Next to MLS data, the platform offers Zillow Group datasets, such as Zestimates and economic data, each with its own approval. For a broker site the MLS dataset is what matters, and every one of those needs the MLS to say yes.
Bridge is where you apply, but every dataset needs the MLS's approval. What the MLS asks for, and whether it says yes, is up to the MLS.
Sign up and create an application. It comes with a client ID, a client secret, server and browser tokens, and automatic access to a test dataset.
Find your MLS in the dashboard and apply. Say what data you need and how it will be used. A vendor should name the brokerage it works for, which speeds up approval.
Some MLSs want a signed data licence, a fee or compliance testing before they approve. A few are not listed and have extra steps.
Access is granted as IDX, VOW, back office (BBO) or another licence. A second feed type from the same MLS needs a second application, unless the MLS combines them.
The sync is built against the test dataset, then pointed at your MLS dataset with the server token once Bridge emails that it is approved.
Bridge documents its limits plainly. These are the ones that shape the sync.
01Property, Member, Office and OpenHouse through the RESO Web API, plus a DataSystem call that lists every dataset your application is approved for.
02Photos come as an object on the Property record, not a separate resource. They are usually the highest resolution the MLS has, stored on Bridge's CDN, which you may link to directly.
03On demand queries return 10 records by default and up to 200 with $top. Anything past 10,000 records has to go through the replication endpoint.
04The /replication endpoint allows $top up to 2,000 and returns records oldest to newest, with a next link to follow. The MLS decides whether you get it, and it is not offered on virtual datasets.
05Bridge recommends BridgeModificationTimestamp for incremental pulls. ModificationTimestamp comes straight from the MLS and does not always change when Bridge updates a record.
06The default is 5,000 requests an hour, with a burst limit of one fifteenth of that each minute. Remaining counts come back in the response headers.
07A combined feed carries a FeedTypes field on each record, and a FieldRules resource shows which fields each licence allows.
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.
Incremental pulls key off BridgeModificationTimestamp rather than the plain RESO field, so changes made on Bridge's side are not missed.
The remaining rate limit is read on every response, and an auth error stops the run instead of hammering the API.
Where your MLS grants replication, the first load and weekly re-syncs use the replication endpoint. Regular runs use a filtered query.
Off market listings are purged daily. If the feed returns too few IDs, the purge is skipped and we get an alert.
The server token stays in server side config, never in theme JavaScript, since Bridge warns that a token in client code exposes the feed. Photos can point at Bridge's CDN, so the media library does not fill up with listing images. The sync runs from a server cron job.
Queued jobs on the scheduler pull changes on BridgeModificationTimestamp and run full re-syncs through replication. The rate limit headers are read on each response, and the job backs off before it reaches the hourly cap. An auth error stops the run.
The sync writes to one listing schema in your database, and your front end reads from there. If your MLS gives you IDX and VOW as a combined feed, the FeedTypes field decides which records each page is allowed to show.
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 Bridge 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.
If your MLS offers Bridge and another platform, the listings are the same and both follow the RESO standard. The choice comes down to fees, whether the MLS grants replication, and how the limits fit the size of your market.
Bridge suits sites that want to link photos straight from a CDN and keep request counts low. The small page size makes replication a must for a large MLS, so it matters whether your MLS allows it.
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.