Imagine one brokerage with three screens: a property search anyone can open, a portal for its registered clients, and a staff tool for transactions. All three may receive records through a Web API. Their audiences and permitted uses differ.
NAR’s MLS policy handbook defines the broad categories. The MLS supplying the data publishes the application process and display rules for its feed.
| Use | Typical audience | Product example |
|---|---|---|
| IDX | Public visitors | Brokerage listing search |
| VOW | Registered brokerage clients | Online brokerage service with listing search |
| Brokerage back office | Broker and affiliated users; some defined client-facing uses | CRM, transaction or management tool |
IDX: a public search
Internet Data Exchange lets a participating broker display eligible listings from other participating brokers under the IDX policy. The site may be built by a vendor, but the participant remains responsible for the use.
Inspect the public screen as well as the feed name. A search card, map pin, detail page, and email alert may show different fields. The local rules govern attribution, permitted listing statuses, seller choices about internet display, and other conditions. A vendor working for two brokerages should be able to identify which participant authorized each display.
VOW: an online brokerage service
A Virtual Office Website provides brokerage services to consumers who have established the relationship described in NAR’s VOW policy. Registration and the broker’s supervision are part of the service. A login box alone does not establish that relationship.
Sketch the visitor’s route through the product: what appears before registration, how the brokerage relationship is established, what a registrant can see, and how access ends. If the same site also has a public search, test the public and registered views separately. A field allowed in one view can be exposed accidentally in the other.
Back office: defined brokerage work
The Brokerage Back Office policy covers brokerage management and specified CRM, transaction, and statistical uses. It identifies who can use the data for each purpose and excludes some MLS-only content. An “internal tool” description is too broad if the application sends reports to customers or lets staff export listing data.
List the actual users: broker, affiliated agents, support staff, and any clients. Then list what each can view, download, or send. The MLS can tell you which back-office or own-listings route fits. REcolorado distinguishes back office from participant access to office listing data. OneKey MLS publishes separate descriptions for VOW, back-office, and own-listings delivery.
Review who can see each screen
AnyProp can help with the application and licensing work for the product’s intended use. During implementation, our MLS profiles endpoint supplies disclaimers and basic compliance elements. A team building one listing-page template can retrieve those source details and apply them to the relevant records. Check the finished page against the approved use and current MLS rules.
A small matrix is useful during review. Put public visitors, registered clients, agents, and administrators in rows; put search, detail, alerts, reports, and exports in columns. For each cell, name the data use and the feed supplying it. This catches cases such as a public alert using a field meant only for a client portal.
NAR’s One Data Source policy allows a participant to request one feed for its licensed uses and have it delivered to a designee. The licensed uses still matter. Keep the approved matrix with the product release so later changes can be reviewed against it.
