A new MLS connection is a starting point for a market launch. The release is ready when the named customer can use the intended feature, the display follows the approved rules, and support can trace a problem back to its source.
Begin with a specific request
Write down the customer, participant, cities or counties, property types, and product screens. Use the AnyProp MLS Directory to find likely organizations, then confirm the service area and request route on the MLS’s own site. A state name is usually too broad to define a launch.
Create one market record with the organization, technical provider, participant, use, agreement, required fields, and owner. Keep dates for approval, first data received, completed tests, and release. Those are separate milestones. REcolorado and OneKey MLS both publish multiple data uses; a working connection does not say which product screen has been approved.
A short status line should tell the next person what is open: “Waiting for broker signature on IDX agreement” or “Rental subtype mapping fails in search.” “Market in progress” hides the task.
AnyProp supports the source onboarding and normalized data delivery through our listing aggregation service. For a rollout, bring the next set of markets and the screens you intend to release. This lets the access work proceed with a clear description of what the application needs.
Once the account is configured, compare the planned sources with the account resources response. Investigate missing access before scheduling the feature for release. Your existing AnyProp client can be the starting point for the new market’s tests, using the same request format and the new source’s sample records.
Prove the feature on real records
Pick examples from the permitted feed that exercise the feature: an ordinary listing, a withheld address, missing coordinates, a status change, and a property that appears in two sources. If the product supports rentals or land, include those records too. Save the source key and expected result for each case.
Inspect the actual search card, detail page, alert, and mobile view. Check attribution and the fields allowed under the MLS’s rules. RESO’s Data Dictionary gives many fields common names, but local extensions and empty fields still need a market-specific decision. If a filter is unreliable in this feed, document its behavior before enabling it.
Follow an update into the public interface. Then test a listing that leaves the approved dataset. The source may use polling, an event stream, or another method; RESO’s EntityEvent specification describes one option. The release test should use the delivery method the customer actually has.
Release with a support path
The market record should name who can contact the MLS or provider, where to see the last successful update, and how to find the incoming record behind a public listing. Decide who can pause the market if updates stall or an incorrect display appears. Check that the rollback also affects caches and saved-search alerts.
Share a precise availability statement with sales and support. “Public search live for this brokerage in these counties” has a testable meaning. The same feed may not yet support a report using older sold records or another participant’s application.
After launch, keep the sample records as regression tests. A mapping fix in one market can alter a shared page or filter elsewhere. Revisit the market record when the participant changes, the product gains another screen, or the MLS revises its rules. The release process should make those changes visible to the people operating the product.
