IDX, MLS and feed integration: what a brokerage website actually connects to

A brokerage website does not connect to “IDX” as a single thing. It connects to a specific data feed, delivered under a specific license, from a specific MLS or data vendor, with specific display rules attached, and the shape of that connection decides whether your listings become indexable pages on your own domain or stay trapped inside somebody else’s search tool. Getting this right at the contract stage is cheaper than discovering it after launch, so here is what each layer actually is, who owns what, and what to check before you sign with a vendor.

IDX, MLS, data feed and vendor widget are four different things

These four terms get used as if they were interchangeable, and they are not. An MLS is an organization and a database, a data feed is a delivery mechanism, IDX is a permission arrangement, and a widget is third-party software. Conflating them is how a brokerage ends up paying for a feed it cannot use the way it wanted to.

What an MLS actually is

An MLS is a cooperative database of listing data maintained by participating brokerages within a market, along with the rules and the organization that govern it. NAR describes the multiple listing service as the means by which participating brokers share information about properties and cooperate with one another, which is the part that matters here: the data exists because brokerages agreed to pool it under rules. Access is tied to membership and participation, not to a purchase.

The operational consequence is that the MLS is a counterparty, not a vendor you can route around. Your access, your permitted refresh rate, your required disclosures and your takedown obligations are all decided there, and a good web team asks what they are before writing a line of integration code.

What IDX actually is

IDX, internet data exchange, is the arrangement under which a participating brokerage may display listings belonging to other participating brokerages on its own public website. It is a permission layer on top of MLS participation, usually with its own agreement, its own opt-in and opt-out mechanics, and its own display rules.

Two things follow. IDX rights and feed access are negotiated separately, so having one does not guarantee the other is configured the way your build needs. And IDX rules are display rules, so they apply to whatever surface shows the listing: a widget, a rendered page, an emailed alert. Building your own pages does not exempt you from them, and does not make them harder to honor either, because the rules can be baked into one template rather than checked by hand.

What a data feed is

A data feed is the technical channel that moves listing records out of the MLS database and into your system. Historically that meant RETS, a bulk pull on a schedule. Increasingly it means a RESO Web API endpoint your system queries directly. Either way the feed is a stream of structured records: a listing key, a status, a price, numeric and text fields, and references to media.

A feed by itself does nothing a visitor can see. What your site does with it, whether it stores it, normalizes it, renders it into pages and keeps it current, is the actual integration work, and it is the part a vendor’s “IDX included” line item may or may not cover.

What a vendor widget is

A widget is a prebuilt search interface, usually an iframe or a script, that a vendor hosts and you embed. The vendor holds the feed, runs the search, and paints results inside a box on your page. It is fast to deploy and it satisfies a checklist item called “we have IDX on the site.”

The cost is control. Listings are served from the vendor’s system into a frame, so the listing content is not yours to structure, mark up or optimize, styling is limited to what the vendor exposes, page speed is partly out of your hands, and the URLs belong to the widget rather than to your site. For one agent with a handful of listings that trade-off can be reasonable. For a brokerage running inventory at volume it caps what the site can ever do.

Who owns the data and who sets the display rules

Nobody on your website team owns the listing data, and that is the correct starting assumption. It is licensed to your brokerage through MLS participation and an IDX agreement, and the license carries obligations the website has to implement.

The license travels with the data

Every display rule applies wherever that listing appears on your site: the listing page, the market page that counts it, the agent page that lists it, the search results, the sitemap, and any feed or AI-readable text file your site generates. A brokerage that honors the rules on the listing page and forgets the search results has still published non-compliant output.

What the rules usually cover

Specifics vary by MLS, so treat this as a list of questions rather than answers. The common categories:

• Attribution. Naming the listing brokerage on listings sourced from another participant, in a prescribed position and wording.
• Source disclosure. A statement identifying the MLS as the data source, often with a last-updated timestamp.
• Opt-out handling. Honoring listing brokers who opted out of IDX display, applied at ingest rather than at render.
• Retention after status change. How long a sold or withdrawn listing may stay displayed, and what must be removed from it.
• Field-level restrictions. Fields delivered in the feed that may not be shown publicly.
• Refresh obligations. A maximum age for displayed data, which sets the floor for your cadence.

What your brokerage does own

Your own photography, your own listing descriptions, your market pages, your agent bios and your site design are yours. The distinction explains why the durable value of a brokerage site accumulates in content your brokerage created rather than in records everyone in the market receives identically.

What to ask your MLS for before the build starts

Ask these before a developer scopes the work. The answers change the architecture, not just the timeline.

1. What feed types are available to us, and at what cost? RESO Web API, RETS, or a vendor-mediated feed only.
2. What is the permitted refresh interval? Get the number in writing, including any difference between full syncs and incremental pulls.
3. Which fields are in our entitlement, and which are restricted from public display? Ask for the field list, not a summary.
4. How is media delivered? URLs to the MLS media host, or files we may download and re-serve from our own storage.
5. How are opt-outs and off-market records signaled? A flag on the record, removal from the feed, or a separate delta list.
6. What are the exact attribution and disclosure strings? Wording, placement and whether a timestamp is required.
7. What is required when a listing changes status or leaves the feed? Removal, partial redaction, or continued display with a status label.
8. Is there a compliance review before launch? Many MLSs will review a staging site, which is far cheaper than a post-launch correction.

A brokerage that walks into a vendor conversation with those eight answers gets a much shorter conversation than one that does not.

The RESO standards and why they change the conversation

RESO standards exist so a listing record means the same thing across markets, which is what makes a multi-MLS brokerage site buildable at all.

The Data Dictionary

The RESO Data Dictionary is a standard vocabulary for real estate data: agreed field names, agreed enumerations for property type and standard status, agreed data types. Its value is a target shape. Rather than modeling your listing record on whatever one MLS calls a field this year, you map every incoming source into dictionary-aligned fields and build every page, filter and template against those.

The payoff arrives the day you add a second source. If your templates read a normalized status field, adding a market is a mapping exercise. If they read a raw source field name, it is a rebuild.

The Web API

The RESO Web API defines a standard way to query listing data over HTTP, with filtering and incremental retrieval, in place of the older bulk-transfer approach. That matters three ways: you pull only what changed since the last sync, you can query subsets such as one office’s listings, and the same code can point at another compliant source through configuration rather than a rewrite.

Confirm which version of the standard your MLS supports and whether your entitlement includes the endpoints you need, since a vendor’s “RESO compatible” claim is not the same as your MLS granting you access.

Refresh cadence and why stale status is the most visible failure

Stale status costs a brokerage the most credibility for the least technical reason, because it is the one failure a visitor can catch without knowing anything about websites.

What the failure looks like from outside

A buyer sees a listing marked active, calls the office, and learns it went under contract over a week ago. An agent sends a link and the price is last month’s price. None of this is subtle, and all of it reads as the brokerage being disorganized rather than the feed being slow.

Setting the cadence

Design the cadence around field groups, not one global number:

• Status and price are the volatile, visible fields. Sync them as frequently as your MLS agreement permits, and build the incremental pull around them.
• Core listing facts such as bedroom count, square footage and description change occasionally and ride the same incremental sync without special handling.
• Media is the heavy part. Re-downloading a full gallery on every sync wastes bandwidth and entitlement, so key media sync to a media-changed timestamp where the feed provides one.
• Full reconciliation still runs on a slower schedule, because incremental syncs miss deletions and silent corrections. A nightly or weekly full pass catches drift.

Failing visibly rather than silently

The sync needs monitoring, and the monitoring needs a human destination. If a sync has not completed within a defined window, somebody is notified, because a feed that quietly stopped days ago is worse than one that never worked. Every listing page should also carry a last-updated timestamp derived from the actual sync rather than from the page build, so a stale page admits it.

Rendered pages from the feed versus an embedded search tool

Rendering pages from the feed means your system holds the listing records and generates a real page per listing on your own domain, with your own URL, title, description, photos and structured data. Embedding a search tool means a third-party interface runs inside your page and the content belongs to that tool. The difference shows up in what each approach makes possible:

• URLs. A rendered page has a permanent, readable URL on your domain that you control and can redirect. A widget’s listing view has a URL controlled by the widget’s own routing.
• Indexing. A rendered page can be listed in your sitemap, and Google’s sitemaps documentation describes sitemaps as a discovery aid that matters most for large sites and pages internal linking alone may not surface quickly. That is a brokerage with hundreds of listing pages.
• Client-side rendering risk. Google’s JavaScript SEO documentation explains that content injected after page load is processed on a separate schedule from the initial crawl, which is the structural reason widget-delivered content is unreliable as indexable content.
• Crawl efficiency. Google’s guidance on managing crawl budget for large sites addresses exactly this kind of inventory and favors a clean URL structure, accurate sitemaps and no endless parameterized variants. A tool that mints a URL per filter combination works against that.
• Measurement. Rendered pages appear individually in your analytics and search performance reports, so you can see which markets and listing types pull traffic. Widget views collapse into one page.
• Speed and design. A rendered page is yours to optimize, from image sizing to layout. A widget is a third-party runtime you inherit.

Most brokerages want both: rendered pages as the durable, indexable inventory, plus a fast search and filter interface built against the same normalized data for people browsing rather than arriving from search.

Field mapping: what to map carefully and what never to publish

Field mapping is where integrations quietly go wrong, because a mapping mistake produces a page that looks fine and says something false.

Fields worth mapping carefully

• Standard status against your display status. The feed’s status vocabulary is richer than what a public page should show. Decide which source statuses roll up into coming soon, active, under offer, sold and off-market, and keep that mapping in one place.
• Listing key and identifiers. Pick the stable key the MLS guarantees, because your URL strategy and your deduplication depend on it.
• Price fields. List price, previous price and closed price are different fields with different display rules, and showing the wrong one is the most damaging mapping error there is.
• Dates. On-market date, status change date, modification timestamp and closed date each drive different behavior. Map them individually rather than collapsing them into one “updated” value.
• Property type and sub-type. These drive filters and market page groupings, so normalize them to a dictionary-aligned set instead of passing raw source values to the interface.
• Media order and captions. Photo sequence carries intent, and a sync that reshuffles galleries on every pull is a recurring agent complaint.
• Listing brokerage and listing agent. Required for attribution, and also the field your enquiry routing reads so an enquiry on your own listing reaches your agent.

Fields to keep out of public output

Some fields arrive in the feed and should never reach a public page, a sitemap, a feed export or an AI-readable text file. Your MLS entitlement sets the exact list, but the categories are consistent:

• Showing instructions, lockbox details, alarm codes and access notes.
• Seller or occupant contact details, and private remarks intended for cooperating agents.
• Compensation fields and broker-to-broker terms.
• Owner names and identity fields attached to the property record.
• Internal MLS remarks and any field flagged as restricted in your entitlement documentation.

The safe pattern is an allow list rather than a deny list. Your public listing object is built by explicitly copying the fields you are permitted to show, so a restricted field added to the feed next quarter cannot leak by default.

What breaks when you change MLS or add a second one

Changing or adding an MLS breaks everything built against a single source’s assumptions, and the damage is proportional to how much of the site read raw source values. The failure points, in roughly the order they bite:

1. Field names and enumerations differ. Templates reading source-specific fields render blank or wrong. This is the case for a normalization layer, stated as plainly as it can be.
2. Identifiers change. A property carried in a new source arrives with a different key, so anything that built URLs from the old key points at nothing.
3. Overlapping coverage creates duplicates. Border markets often appear in both sources. Without a deduplication rule you publish two pages for one property, which splits internal linking and leaves you maintaining two addresses for one thing.
4. Display rules multiply. Each source brings its own attribution string, disclosure and retention rules, so the template needs per-source rules rather than one hardcoded footer.
5. Refresh entitlements differ. Two permitted cadences means monitoring is per-source and the last-updated timestamp is per-listing rather than site-wide.
6. Historical URLs need a decision. A listing that existed under the old source and still exists under the new one keeps its URL and is remapped internally, rather than republished at a new address.

Handled deliberately, adding a source is configuration plus a mapping table. Handled late, it is a second integration bolted onto a site that assumed there would only ever be one.

A checklist for evaluating a vendor

Work through these in a live conversation rather than from a proposal document, because the interesting answers are the hesitant ones.

1. Does each listing get a permanent URL on our own domain, rendered server-side? Ask to see one in a browser with JavaScript disabled.
2. Do we hold our own copy of the listing data, or does it live only in your system? This decides whether leaving you is a migration or a restart.
3. Which feed do you connect to, and is the agreement in our name? A feed held by the vendor is a dependency you cannot transfer.
4. What is the sync interval per field group, and how are failures escalated? Ask what happens at two in the morning when a sync fails.
5. How are restricted fields handled, allow list or deny list? The answer tells you how the integration was designed.
6. What happens to a listing page at each status change and at removal from the feed? Listen for an automated rule, not a manual process.
7. How do you handle a second MLS? Even with one today, the answer reveals whether there is a normalization layer.
8. What is in the sitemap, and how quickly does a new listing appear in it? A sitemap regenerated weekly is a week of invisibility per listing.
9. Who owns the URLs, the templates and the photography we upload, and what does an exit look like? Get the export format, the redirect map and the retention period in the contract.

A vendor who answers all nine without deflecting is selling an integration. One who answers two is selling a widget with an invoice attached.

Where this leaves a marketing director

The decision that matters is not which vendor has the nicer search interface. It is whether your inventory ends up as pages you own on a domain you control, built on data normalized to a standard so a second market is a configuration change, with a cadence tight enough that status is never embarrassing and a field policy strict enough that nothing restricted can leak.

To see this applied to your own feed and roster, book a demo, or start with IDX website development for brokerages and MLS integrated website development. The companion piece on brokerage website architecture covers what the pages should look like once the feed is connected.