MLS and IDX Integration: A Developer's Guide to RESO and Display Rules

MLS integration means replicating listing data from a Multiple Listing Service, usually over the RESO Web API, and displaying it under that MLS's rules. IDX lets brokers show other brokers' listings publicly; a VOW serves a broker's registered clients under stricter sign-up rules. Access comes first: your MLS grants it to a participating broker and the vendor they authorise.

A straight statement before the detail: RAITHub does not cite a live MLS integration. Whether your product can use MLS data depends on your MLS granting access, and RAITHub would scope that integration as new work once access is confirmed. This guide is the developer explainer we would want to read before that scoping call. The wider PropTech picture, including the platforms RAITHub has built, is in the PropTech software development pillar.

What are MLS, IDX and VOW?

An MLS is a regional database of listings that member brokers share. IDX and VOW are the two policies, set out by the National Association of REALTORS® (NAR) and adopted by each MLS, under which brokers can show that data to consumers online.

Term	What it is	Who sees the data
MLS	A regional listing database run for its participating brokers	Brokers and agents who are members
IDX (Internet Data Exchange)	Lets participants display other participants' listings on their own websites and apps	The public
VOW (Virtual Office Website)	A broker's site delivering brokerage services to registered consumers	Registered consumers with a broker relationship
RESO	The standards body behind the Data Dictionary and the Web API	Developers and MLS vendors

Sources: NAR's IDX policy, Policy Statement 7.58 and VOW policy. Individual MLSs add their own rules on top, so the local MLS's policy is always the one to read.

Who can get MLS data access, and how does licensing work?

Not a software company on its own. Access is granted by the MLS to a participant, a broker, or an agent under one, and to a technology vendor that participant authorises. The IDX policy requires every IDX display to be under the participant's "actual and apparent control" and presented as the participant's display.

In practice the order is:

1. Find the participant. A broker who is a member of the MLS you need, and who will sponsor your product's access.
2. Sign the agreements. Usually the broker's IDX or VOW agreement with the MLS, and a vendor licence agreement for you as the technology provider.
3. Pay the fees. Set by the MLS or its data vendor, and recurring. AppZoro's July 2026 breakdown puts licensing for one MLS through an aggregator at $3,000–$15,000 a year, plus per-MLS certification fees of $1,000–$10,000 a year (AppZoro).
4. Receive credentials. Then read that MLS's display rules and build to them.

Timelines for approval are set by the MLS, not by the developer. No developer can promise a live feed before access is granted. Outside the US and Canada the model is different: in the UK, for instance, listings usually reach consumers through commercial property portals fed by agents' software, not through an MLS.

How does the RESO Web API work?

It is a REST interface on the OData V4 standard that returns JSON, secured with OAuth, and the field names come from the RESO Data Dictionary. RESO describes RETS, the older transport, as deprecated and no longer supported, so new builds should target the Web API (RESO Web API FAQ).

• Resources. The Data Dictionary defines resources such as Property, Member, Office, Media and OpenHouse, with standard fields like ListingKey, ListPrice, StandardStatus and ModificationTimestamp.
• Versions. Data Dictionary 2.0 was ratified in December 2023 and depends on Web API Core 2.0.0 (RESO Data Dictionary specification). RESO certifies MLS systems against these, so a certified feed uses the standard names.
• Local fields. Every MLS also sends fields of its own. Map the standard ones once and treat local fields as per-MLS configuration.
• Querying. OData query options do the work: $filter, $orderby, $top, $select and $expand.

An incremental request for recently changed listings looks like this:

GET /Property?$filter=ModificationTimestamp gt 2026-09-28T00:00:00Z
      and ModificationTimestamp le 2026-09-28T01:00:00Z
    &$orderby=ModificationTimestamp asc
    &$top=200
Authorization: Bearer <access token>

Follow the @odata.nextLink in each response until there is none, then advance your cursor. For development without live credentials, RESO runs a Web API reference server with sample data.

What is the difference between IDX and VOW rules?

IDX is public display with lighter sign-up and a faster refresh rule; VOW is for registered clients with a broker relationship and has its own limits. The table sets out what NAR's two policies say; your MLS may be stricter.

Rule	IDX (Policy Statement 7.58)	VOW policy
Audience	The public	Registered consumers with a lawful broker relationship
Registration	Not required by the policy	Name, verified email, unique username and password, and agreement to terms of use
Refresh	At least every 12 hours	At least every 3 days
Seller opt-out	Listings or addresses withheld by the seller must not be accessible	Sellers can opt out of display of the listing or address
Third-party comments and automated valuations	Sellers can ask for these to be disabled on their listing	Sellers can ask for these to be disabled on their listing
Result limits	MLS may limit consumer downloads, but not below 500 listings or 50% of IDX listings, whichever is less	MLS may limit how many listings a registrant retrieves, within floors the policy sets

One more rule changed recently. Since NAR's Multiple Listing Options for Sellers policy (effective 25 March 2025, to be implemented by 30 September 2025), a seller can choose a delayed-marketing exempt listing that other MLS participants can see but that stays out of IDX and syndication for a period the local MLS sets (NAR: Multiple Listing Options for Sellers). Your sync has to respect that status as soon as it changes.

How should you sync MLS data into your own database?

Replicate, do not query live on every page view. Pull changes by ModificationTimestamp in bounded windows, store raw records, map them into your own model, and run a reconciliation job to remove listings that are no longer in the feed. RESO distinguishes replication, continually requesting the most recent changes, from live queries (RESO Web API); display products almost always replicate.

Job	Suggested frequency	What it does	What must hold
Incremental sync	Well inside the MLS's refresh rule, often every 15 minutes to an hour	Fetches records changed since the last cursor	The cursor advances in the same transaction as the batch it covers
Media sync	After each incremental batch	Downloads and resizes changed photos	A listing never shows another listing's photos
Reconciliation	Daily	Compares all keys in the feed with your store and removes the missing	Off-market and withdrawn listings disappear from display
Freshness check	Continuous	Alerts when the last successful sync is too old	You find out before the 12-hour IDX limit, not after

Four details that decide whether the sync can be trusted:

• Bound both ends of the window. A lower and an upper ModificationTimestamp, ordered ascending, so records modified during the run are picked up next time rather than skipped.
• Handle deletions explicitly. RESO noted in March 2024 that there was no good standard way to learn which records have left a feed, so consumers usually run a daily reconciliation that queries all keys. Its EntityEvent resource, an append-only log of creates, updates and deletes, is the newer answer where an MLS supports it (RESO: EntityEvent resource).
• Keep an anti-corruption layer. Store each feed's raw record, then map it into your own listing model. A second MLS then means a second mapping, not a schema change.
• Make every job safe to run twice. Upserts keyed on ListingKey and the source MLS, never blind inserts. The same discipline applies to any scheduled job; on PropDesk, a property management platform RAITHub built, 5 daily automation jobs are covered by the 1,024-test suite.

MLS APIs usually rate-limit clients, so the sync should back off and resume from its cursor rather than fail; see API rate limiting explained.

What display rules does an IDX listing page have to follow?

At minimum, the rules in NAR's IDX policy, plus whatever your MLS adds. Treat them as part of the page template, so no listing can render without them.

• Your brokerage's name. The display must clearly identify the name of the participant's brokerage firm "in a readily visible color and typeface".
• The listing firm. Each listing must identify the listing firm and the email or phone number the listing participant provided, in a reasonably prominent location.
• No editing others' listings. Participants "shall not modify or manipulate information relating to other participants' listings".
• Excluded data. MLSs may bar confidential fields meant for cooperating brokers, such as showing instructions and security information, and seller or occupant contact details.
• Disclaimer. MLSs may require a notice that the data is deemed reliable but not guaranteed accurate by the MLS.
• Freshness. Displays fed from MLS downloads must be refreshed at least every 12 hours.

Search is covered by other law too. In the US, the Fair Housing Act prohibits advertising that indicates a preference or limitation based on race, color, religion, sex, disability, familial status or national origin (HUD). Keep filters to property attributes. None of this is legal advice; your broker and your MLS are the authorities on its rules.

Should you build an MLS integration or use an IDX vendor?

Use an approved IDX vendor first if the goal is listings on an agent or brokerage website. Build when the display a vendor allows is too limiting for your product, or when the data has to feed your own features.

Approach	Fits when	Trade-off
Turnkey IDX plugin or embed	One agent or brokerage site needs search now	Fast, but little control over design, page structure or data
Data aggregator feed	A product needs several MLSs in a normalised format	One integration, but MLS agreements and display rules still apply per MLS
Direct RESO Web API integration	One or a few MLSs; full control of data and pages	You own mapping, sync, freshness and compliance for each MLS

AppZoro's July 2026 figures put one-time engineering for a single MLS at $20,000–$50,000 and for 5–10 MLSs at $80,000–$200,000. The rest of the budget picture is in the cost to build a real estate platform.

What should you bring to a scoping call for MLS work?

The MLS's name and who holds the relationship with it. Without those, nobody can estimate the work honestly.

• Which MLS or MLSs, and in which markets.
• The participating broker who will sponsor access, and whether they have agreed.
• Whether you need IDX, VOW or data for back-office use only.
• The status of the vendor agreement and any fees already quoted.
• The MLS's display rules document, if you have it.
• What the data must feed: search pages, alerts, a CRM, analytics.

How does RAITHub approach MLS work?

Honestly, and as new work. RAITHub will tell you on the first call that it has no live MLS integration to show, and that your MLS's access decision comes before any estimate for the feed.

What RAITHub can point to is the platform around a feed. BlockEstate is a multi-tenant listing and inquiry platform with listing intake, agent dashboards, lead routing and a document workflow, each brokerage isolated as a tenant, and an MVP shipped in 6 weeks. PropDesk shows tested scheduled jobs at scale. How a platform like BlockEstate is structured is in how to build a real estate marketplace, and sync and integration backends are built under API and backend development. RAITHub is a founder-led studio, founded in 2024 in Dhaka and working with clients worldwide, offering fixed-scope builds or a dedicated team.

When RAITHub isn't the right fit: if a live feed is the core of the product and you or your investors need a vendor with shipped integrations on your MLS, choose an approved IDX vendor or a firm with that track record. The same applies if you need the feed live before access is granted, want developers placed under your own management (RAITHub does not do staff augmentation), or need a SOC 2 or ISO 27001 certified vendor; RAITHub is not certified.

If you have your MLS and a sponsoring broker, book the free 15-minute technical audit. What is included is on the PropTech service page.

Last reviewed: 29 September 2026. Policy details are as published by NAR and RESO on that date; your MLS's current rules take precedence.

Frequently asked questions

What is the difference between IDX and VOW?

IDX lets brokers display other brokers' listings to the public and must be refreshed at least every 12 hours under NAR Policy Statement 7.58. A VOW serves registered consumers who have a broker relationship, requires verified sign-up, and must be refreshed at least every 3 days.

Can a software company get MLS access without a broker?

Generally no. The MLS grants access to a participating broker, or an agent under one, and to a technology vendor that participant authorises. Your product's access depends on that sponsorship and on the MLS's approval.

Is RETS still used, or should I build on the RESO Web API?

Build on the RESO Web API. RESO describes RETS as deprecated and no longer supported. The Web API uses OData V4, JSON and OAuth, with field names from the RESO Data Dictionary.

How do you detect listings that were removed from an MLS feed?

Run a daily reconciliation that compares every key in the feed with your store, as RESO says most consumers do, or use the EntityEvent resource where your MLS supports it, since it records deletes as events.

How much does MLS integration cost?

AppZoro's July 2026 breakdown puts one-time engineering for one MLS at $20,000–$50,000 and licensing at $3,000–$15,000 a year. These are market figures; RAITHub publishes no rates.

Has RAITHub built MLS integrations?

RAITHub does not cite a live MLS integration. It would scope MLS work as new work once your MLS grants access, on top of listing platform experience from BlockEstate.

“I want to show MLS listings on my site but the rules and feeds confuse me – where do I even start?”

Start by securing MLS access through a broker or participant, since a software company cannot get it alone, and ask which IDX display rules apply. Build on the RESO Web API rather than legacy RETS, and plan for detecting removed listings. Get one feed syncing correctly, with display rules honoured, before scaling to more MLSs.

Who owns the integration code and will RAITHub hold our MLS credentials?

You own the integration; RAITHub assigns the intellectual property, hands over the repository and documentation, and signs an NDA. MLS credentials and feed data live in your own infrastructure under your controls, with a DPA where personal data is involved. RAITHub does not retain your feed or credentials after handover.

“I have broker sponsorship lined up — is there a development company that can build and maintain our MLS/IDX feed sync?”

Yes. Once your broker or participant grants access, a team can build the RESO Web API sync, honour the IDX display rules, and keep it reconciled daily. RAITHub would scope this as new work, drawing on listing-platform experience from BlockEstate, since it does not cite a live MLS integration. It starts with a free 15-minute audit, then a written quote.

Should I build a RESO Web API sync myself or buy an aggregator like a third-party IDX feed provider?

Aggregators are faster to launch and normalise many MLSs for you, but you inherit their field mapping, refresh timing and display-rule handling. A custom RESO Web API build gives you control over reconciliation, your own data store and no per-listing markup. Choose the build when the feed is core to your product rather than a widget.

How long does it take to get one MLS feed syncing correctly?

The engineering is usually a few weeks once access is granted, but the gating item is the MLS approval and onboarding, which can take longer and is outside your control. The work involves RESO Web API authentication, mapping Data Dictionary fields, daily reconciliation for removed listings, and honouring the IDX refresh and display rules.

Can I just use an AI tool to wire up the MLS feed for me?

An AI can draft RESO Web API calls and explain OData queries, but it cannot obtain broker sponsorship, satisfy each MLS’s display rules, or reconcile deletes against a live feed you have not shared. The compliance-with-MLS-policy and reliability work is where integrations fail, and that still needs an engineer who can test against the real feed.