Before requesting an MLS feed, describe the product, the brokerage participant, and the people who will use it. Those details determine which data use the MLS needs to review. A public listing search and an internal reporting tool may need different approvals even when the same company builds both.
Describe one product and its users
Write down the screens the customer will actually use. A public property search, a saved-search area for brokerage clients, and an internal pricing dashboard may need different permissions even if they use records from the same MLS. Include email alerts, mobile apps, exports, and any stored photos or sold records. Name the brokerage participant and the company operating the software.
This gives the MLS something to classify. NAR’s data policies cover public IDX display, Virtual Office Websites, and brokerage back-office work separately. The local MLS then applies its own agreement and display rules. If your product uses data for analytics or model development, say so in the request; a public-display agreement may address a different use.
A one-page brief can be enough for the first conversation:
| Item | What to provide |
|---|---|
| Participant | Brokerage and responsible broker |
| Operator | Vendor or internal team running the application |
| Audience | Public visitors, registered clients, agents, staff |
| Surfaces | Search, detail pages, alerts, reports, exports |
| Data | Property types, statuses, media, sold history, local fields |
| Handling | Storage, refresh, removal, access controls |
Add screenshots if the interface exists. An MLS reviewer can answer a concrete question about a screen more readily than a broad question about data access.
Identify the organizations for the launch markets
Start with the cities or counties the first customer needs. Use the AnyProp MLS Directory to find likely organizations, then check each organization’s site for its current service area. The office address in a directory record is not a coverage map.
Make a row for every market with the MLS name, brokerage participant, intended use, official request page, and person responsible for the application. Add the technical delivery platform only after the MLS identifies it. OneKey, for example, describes MLS Grid as its Web API delivery route; the approved use is still selected for the product.
The application steps vary. REcolorado asks vendors to create a Bridge application, describe the intended use, request its dataset, and complete a license review. Maine Listings says its vendor feeds serve active subscribers and cannot be redistributed to unrelated customers. Those are useful reminders to keep the participant and customer attached to each request.
AnyProp helps coordinate the applications and licensing work for these requests through our MLS approval service. Send us the brief, the brokerage details, and the markets you want to launch. We can use that information to discuss the intended use with the relevant organizations and connect the access work to the data your engineers need.
Verify the first feed in the product
For an AnyProp integration, first check GET /v1/account/resources, which reports account settings and permissions. This gives the developer a place to check the account before writing queries. Compare the returned listings with the screens in the brief so the access request and the implementation stay aligned.
Once access is approved, test more than a successful API response. Save examples of the property types and statuses the feature needs. Check listing attribution, missing addresses, photos, and a record that changes status. See how a listing is removed from the public screen when it leaves the permitted feed. Write down fields that are empty or local to the source.
Keep the approval, test records, and finished screen together. That file becomes useful when someone adds another brokerage, changes the public page, or asks why one listing is absent. For the permission categories, see IDX, VOW, and back-office feeds.
