MLS integration means getting listing data from your Multiple Listing Service onto your website or into your CRM, under the rules your MLS sets. In the US that usually happens through an IDX display license and a data feed, today most often a RESO-compliant Web API. This guide covers how the pieces fit, what the compliance rules say, how to keep a CRM and a website in sync, and how to automate a website for each new listing.
TL;DR
- MLS integration is a permission plus a feed: your MLS authorizes display, and a vendor or your own developer pulls the data, increasingly through a RESO Web API.
- IDX data may only be used for IDX display, must be refreshed automatically and must identify the brokerage. Your MLS's own rules decide the details.
- Get broker sign-off and MLS approval before you write code. Vendors and feed pricing vary by MLS.
- Once listing data sits in your CRM, you can trigger a website for each new property through the Yuppsy API or MCP using your own templates.
- Keep the pipeline small: one trigger, a fixed field map, a template, a publish step and a check that the data refreshes.
Table of Contents
- What MLS integration actually means
- Feeds, IDX and APIs: how they differ
- The compliance rules you cannot skip
- Ways to add MLS listings to an agent or agency website
- Connecting your CRM and website so listing data stays in sync
- Automating a website for every new listing
- A safe build order for developers and CRM admins
- Perspective
- Plans for automated property websites
- FAQ
- Sources
What MLS integration actually means
People use "MLS integration" for three different jobs, and mixing them up is the most common source of wasted budget.
- Displaying MLS listings on a public website. This is IDX. NAR's IDX policy lets MLS participants authorize limited electronic display of listings on public websites and mobile apps they control.
- Feeding a CRM or back-office system. Brokerage software pulls listing data so agents are not re-keying addresses, prices and photos.
- Showing listings to signed-in users. That is a VOW (Virtual Office Website). VOW policies apply to authenticated consumer portals, while IDX governs public-facing search sites.
The Council of MLS explains that IDX is intended for consumer-facing websites and apps. The same document says IDX rules vary by MLS and by state law. Treat any generic checklist, this one included, as a map and your MLS rulebook as the territory.
Feeds, IDX and APIs: how they differ
These terms sit on different layers, which is why they are not alternatives to each other.
| Term | What it is | Layer |
|---|---|---|
| IDX | The permission and rules for displaying listings publicly | Policy |
| Data feed | The actual delivery of listing records to a vendor or broker | Delivery |
| RESO Web API | The current standard way to deliver that data | Technology |
| FTP and RETS | Older delivery methods | Legacy technology |
| iFrame search | A hosted search embedded in your page | Display shortcut |
The Council of MLS says the preferred current delivery method is a RESO-compliant Web API, with FTP and RETS as older methods. Its advice to data consumers is practical: clarify exactly what data you need, then pick the appropriate feed and use a RESO-approved API.
For a developer this matters because a Web API is a normal REST-style integration. You authenticate, query, page through results and store what you are allowed to store. You are not scraping or parsing flat files.
The compliance rules you cannot skip
An integration that works technically but breaks MLS rules can cost an agent their data access. Four themes come up again and again in the documents we reviewed.
Use and control
NAR's IDX policy says IDX-provided listings may be used only for IDX display. That means no reusing the feed to power unrelated marketing, lead lists or third-party products. The same policy says the data may not be made available to unauthorized persons or entities, so API keys and database access need real access control.
NAR's Code of Ethics guidance adds that IDX displays must be under the participant's actual and apparent control and presented to the public as the participant's own display.
Refresh frequency
The sources are not identical here, which is itself a lesson. NAR's IDX policy text calls for automatic refreshes at least every three days, while NAR's Code of Ethics guidance says displays must update at least every 12 hours. Many MLSs set their own, stricter number. Build for the tightest rule you might face, and a sync that runs more often than that gives you room.
Brokerage identification and source labeling
The NAR policy requires that the brokerage be identified prominently. When a site shows listings from several sources, MLS Now's rules require that each listing's source is clearly identified and that users get a filter to limit results to MLS-sourced data. Put the brokerage name and source label in your template, not in a manual step someone can forget.
Paperwork
At MLS Now, an agent's IDX application must be signed by the broker and the agent and submitted to the MLS. Other MLSs have their own forms, but the pattern of broker consent plus MLS approval is common.
Ways to add MLS listings to an agent or agency website
There are three practical routes, and the right one depends on how much control you need.
1. A hosted IDX search embedded in your site. MLS Now members, for example, can use a Matrix IDX link embedded in an iFrame. It is quick and low-maintenance. You get the MLS's search experience, with limited control over design and SEO.
2. A vendor-supplied feed. The same MLS offers a Trestle IDX feed through an approved vendor. The broker approves the vendor's request, MLS Now gives final approval, and the vendor selects the feed and the pricing. Budget for that approval chain, because it takes calendar time that no code can shorten.
3. Your own integration on a Web API. A brokerage with developers can pull listings through a RESO Web API into its own database or CRM and publish from there. You carry the maintenance, but you control the data model and the front end.
Notice what these have in common: before anyone writes code, someone with authority at the brokerage signs, and the MLS approves. Start that process first.
Connecting your CRM and website so listing data stays in sync
Once you have a legitimate feed or a CRM that already holds your listings, the design question is which system is the source of truth. The cleanest answer is one: the CRM or property management system holds the record, and everything else, including websites, reads from it or is triggered by it.
A sync that holds up has a few parts:
- A stable identifier. Use the MLS number or your own internal ID as the key, never the address, which can be edited.
- A field map. Decide once how price, status, beds, baths, description, photos and agent contact map to website fields, and write it down.
- Status handling. Pending, sold and withdrawn listings must change on the site, and some MLS rules limit what can still be shown. Check yours.
- A refresh schedule. Run it more often than the tightest rule that applies to you.
- Logging. Every create, update and failure gets a log line, so someone can answer "why is this listing stale?" in a minute.
For a deeper look at where listing data comes from and how developers use it, see our guide to the real estate listing API. If your side of the problem is the property management system, what to automate first is a good companion read.
Automating a website for every new listing
This is where MLS integration usually stops being a data problem and becomes a publishing problem. Listing data arrives in the CRM, and someone still has to build a page for it. For a listing worth a dedicated page, that is repetitive work that scales badly.
The workflow we built Yuppsy around looks like this:
- A new property enters your system. An agent adds a listing to your CRM, database or property management platform.
- Your workflow triggers Yuppsy. An automation calls the Yuppsy API, or an AI agent connected through Yuppsy MCP does it.
- Yuppsy creates the website. The property information populates a website based on the template and website model you selected.
- The site goes into your publishing flow. You review and publish it as part of your normal process.
Two integration styles cover most teams:
- API. The fit for developers and CRM admins who want to wire listing events straight to website creation. A webhook fires when a record is created, your code maps the fields and calls the API.
- MCP. The Model Context Protocol lets a compatible AI agent interact with Yuppsy directly. It suits flexible, conversational or agent-driven workflows. Our article on MCP integration for real estate explains how it works and when to choose it.
One point on scope: the MLS permission question stays with you. Yuppsy generates websites from the property information your workflow sends it. Make sure that the data you send, and the way the finished site displays it, fit your MLS's display rules. If a listing's data is your own (an exclusive, an off-market property, a rental you manage), the path is simpler still. For what a dedicated page should contain, see what a single property website is and how to automate it.
A safe build order for developers and CRM admins
Here is a sequence that avoids the usual rework.
- Confirm what you may use. Read your MLS's IDX and VOW rules, and get broker consent in writing.
- Choose the delivery route. Hosted search, vendor feed or direct Web API, as above.
- Define the trigger. For most CRMs it is "listing created" or "status changed to active." Avoid triggering on every edit.
- Write the field map. Include required disclosures, the brokerage name and source labels as template fields.
- Make the call idempotent. If the trigger fires twice, you should get one website, not two. Store the returned site ID against the listing ID.
- Handle status changes. Decide what happens on sold, withdrawn or expired.
- Test with three or four real listings. Include one with few photos and one with a long description.
- Monitor. Alert on failed calls and on listings that have not refreshed inside your rule window.
Safeguards worth adding on day one: keep credentials in a secrets manager, give each integration its own key with the least access it needs, and restrict who can trigger creation. Yuppsy includes user permissions and bulk property and agent management for the team side of this.
Perspective
Most teams treat the MLS feed as the hard part and the website as an afterthought. In our experience that gets it backwards. The feed is a one-time approval process with clear rules. The website is the thing you repeat every time a listing goes live, and it is where hours disappear.
That is why we built Yuppsy so the trigger lives in the system you already use. When a property enters your CRM, your workflow can call our API, or an AI agent can reach us through MCP, and a site is created from the template and website model you chose. The result is consistent branding on every listing without a designer in the loop each time.
We also think the right unit is the individual property. A page that exists for one home can carry its own story, photos and contact path, and it scales because creation is automated rather than hand-built. Keep the compliance work with your broker and MLS, keep the data clean in your CRM, and let the publishing step run on its own.
roberto scutaru
Plans for automated property websites
If your listing data already lives in a CRM, you can start with the plan that matches the sites you create. Yuppsy lists a single property website at $4.00 per month, an agent website at $6.00 per month and a company website at $10.00 per month, with 3 property websites available at $0 one-off to try the workflow. Bundles are available too: Silver (1 company, 3 agents, 10 properties) at $60 per month, Gold (1 company, 10 agents, 30 properties) at $180 per month and Platinum (1 company, 20 agents, 60 properties) at $350 per month. Extra storage tiers run from $15.00 per month for 500 MB. See the current Yuppsy pricing and plans.
Individual agents who want a personal site alongside listing pages can read our guide to a realtor personal website. Once the pages are live, the next job is traffic, and our buyer lead tactics cover that.
FAQ
Is MLS integration the same as IDX?
No. IDX is the policy that permits public display of MLS listings, while integration is the technical work of getting the data to your site or CRM. You need the permission first, then a delivery method such as a hosted search, a vendor feed or a RESO Web API.
Do I need my broker's approval to put MLS listings on my website?
In general, yes. At MLS Now, an agent's IDX application must be signed by both the broker and the agent and submitted to the MLS. For vendor feeds, the broker also approves the vendor's request. Check your own MLS for its exact process.
How often does MLS data have to refresh on my site?
It depends on the source. NAR's IDX policy text says at least every three days, and NAR's Code of Ethics guidance says at least every 12 hours. Your MLS may set its own rule, so build to the strictest one that applies to you.
Can I use the same MLS feed for email marketing or lead lists?
Not under the NAR IDX policy, which says IDX-provided listings may be used only for IDX display. Keep the feed for the website display it was licensed for, and use your own CRM data for other marketing.
How do I create a website automatically when a new listing is added?
Set a trigger in your CRM for a new or activated listing, map the listing fields, and call the Yuppsy API with your chosen template and website model. If you use an AI agent, it can do the same through Yuppsy MCP. Store the returned site ID against the listing so repeated triggers do not create duplicates.
Sources
- NAR Internet Data Exchange (IDX) Policy
- Council of MLS: Partnering with Data Consumers
- NAR Code Comprehension: Article 12
- MLS Now Rules: Section 9, IDX and VOW Digital Display Policy
- MLS Now: IDX Setup