MLS Real Estate API: What You Get When You Cannot Get MLS
MLS access needs a licence and a broker. Two public sources returned 40 listings and 48 agents with phones. What they carry, and what they do not.
Copy this line to your agent to pull listings and agents for a market.
set up https://monid.ai/SKILL.md and use homes.com /search_properties_for_sale to pull listings for a city
Almost everyone searching for an MLS API is going to be told no. MLS systems are member associations: access needs a real estate licence, a sponsoring broker, and a signed data agreement per MLS, of which there are hundreds. That answer is correct and useless on its own, so this guide covers the part nobody writes down: what the public sources return instead, measured on 2026-09-02, and where the gap actually bites. It runs through Monid, the OpenRouter for agent tools.
Is there an MLS API you can just sign up for?
No, and the reason matters because it shapes every workaround.
What an MLS actually is
A regional database owned by a member association of brokers, who contribute their own listings and agree on rules for using each other's. There are hundreds of them in the US, each with its own contract, its own field conventions and its own approval process. There is no single national MLS and no national MLS API.
What that means for access
Access is granted to licensed agents and brokers, and to vendors those brokers sponsor. If you are building a product for agents, your route is real: partner with a brokerage, sign the data agreement, and pull an IDX or RESO Web API feed. If you are not, no amount of API shopping produces MLS credentials.
What the portals are
Zillow, Homes.com and the rest are downstream of MLS feeds plus their own agent-submitted data. They are not the MLS, they carry a subset, and they add things the MLS does not have, like their own valuation estimates and review counts.
Why the workaround is often good enough
Because most people asking for MLS do not need MLS. They need current asking prices in a market, or they need to reach the agents working it. Both are on public pages, which is a very different problem from getting licensed. The Zillow listing guide covers what a single listing record carries in detail; this guide is about coverage and access rather than fields.
📖 See also Zillow Scraper: What the Listing Actually Carries
Why does the same query return two different shapes?
Because you are not looking at property data. You are looking at each portal's internal model of a page, and those models are nothing alike.
The measurement
The same request, "agents in Austin, TX", to two providers on 2026-09-02.
homes.com/search_agents returned 48 rows, flat:
{
"name": "Amy Keillor",
"profile_url": "https://www.homes.com/real-estate-agents/amy-keillor/xzjksgm/",
"agent_id": "xzjksgm",
"name_slug": "amy-keillor",
"phone": "(737) 377-3278",
"brokerage": "Teifke Real Estate",
"photo_url": "https://imagescdn.homes.com/i2/..."
}
zillow/search_agents returned 15 rows, shaped like this:
{
"__typename": "AgentDirectoryFinderProfileResultsCard",
"cardActionLink": "https://www.zillow.com/profile/Realty%20Austin",
"cardTitle": "Realty Austin Compass",
"encodedZuid": "X1-ZUz4xwivip62vd_1y8fb",
"isTopAgent": false,
"profileData": [ ... ],
"reviewInformation": { ... },
"tags": [ ... ]
}
What the difference is
One is a contact record. The other is a UI card. __typename: "AgentDirectoryFinderProfileResultsCard" is Zillow's GraphQL type for a search-results tile, and profileData is a nested array of display rows rather than named fields. Neither is wrong. They are answers to different questions: "who is this agent" versus "what does this card render".
Which one you want
If your job is outreach, homes.com gave you a phone number in a top-level field and three times as many rows. If your job is reputation or ranking, Zillow carried isTopAgent, reviewInformation and tags, none of which homes.com returned at all.
The general rule this illustrates
A portal endpoint returns the portal's model, so the field set tells you what that portal's product cares about, not what real estate data is. This is exactly why one source is rarely enough, the same argument as why one Google Maps scraper is not enough, and it is a better reason to use two sources than any coverage claim.
How do you get listing and agent data today?
Three steps. Discovery is free.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Pull the for-sale listings for a market
What it does. Returns current asking prices with the listing agent attached.
The endpoints. homes.com/search_properties_for_sale, billed per call. Required parameter is location; property_type and page are optional.
The call.
monid run -p homes.com -e /search_properties_for_sale --query '{"location": "Austin, TX"}'
What comes back. On 2026-09-02, 40 listings. One row:
{
"address": "4504 Halliday Ave, Austin, TX 78725",
"price": "$255,000",
"beds": 3,
"baths": 2,
"sqft": 1344,
"agent": "Lila Hardegree",
"brokerage": "Real Broker, LLC",
"url": "https://www.homes.com/property/4504-halliday-ave-austin-tx/egvld1llvn62p/"
}
Note agent and brokerage on the listing itself. That is the field people usually go looking for a second source to get, and it is why this endpoint answers more questions than its field count suggests. Note also that price is a formatted string with a dollar sign and commas, not a number, so parse it before you compare anything.
What it costs. A cent per call. Current figures at monid.ai/tools.
Step 2. Pull the agents working that market
What it does. Gives you the people, with contact details.
The endpoints. homes.com/search_agents for flat contact rows, zillow/search_agents for reputation signals. Both per call.
The call.
monid run -p homes.com -e /search_agents --query '{"location": "Austin, TX"}'
What comes back. 48 rows on 2026-09-02 with phone and brokerage populated. Run the Zillow one too when you care about isTopAgent and review counts, and expect to write a small adapter for its card shape. Selector-shaped parsing like that is exactly what breaks first, per the XPath guide.
What it costs. One to two cents per call.
Step 3. Check what you got before you trust the count
What it does. Catches the failure this category produces, and it produced one today.
The call. loopnet/search_listings covers commercial property and takes location, transaction_type, property_type and price and acreage bounds. On 2026-09-02 it returned HTTP 502 from Cloudflare, twice, on two separate calls minutes apart:
{
"title": "Error 502: Bad gateway",
"status": 502,
"detail": "The origin web server returned an invalid or incomplete response..."
}
That is an honest, loud failure and it is the good case. The bad case is a 200 with an empty array, which reads as "no properties in this market" and is indistinguishable from a real answer. So assert on the count:
rows = resp.get("listings") or []
if len(rows) < EXPECTED_FLOOR: # a metro is never a 3-listing market
quarantine(location)
We wrote up the same shape at length in the Amazon ASIN guide after an endpoint returned 26 fields and no values.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to pull for-sale listings and agents for these five metros, and tell me which metros returned suspiciously few rows.What does public listing data not carry?
The honest gap list, because this is where the workaround stops working.
Sold prices and dates
The single biggest one. What a property sold for and when is MLS data, and in non-disclosure states it is not public at all. Portals show some sale history, unevenly, and it is the field most likely to be missing exactly where you need it. Treating a missing field as a zero is how a valuation model quietly goes wrong, which is the argument in web scraping vs API. If your product prices anything, this is a real blocker rather than an inconvenience, and it is the same buy-versus-build wall described in the firmographics comparison.
Days on market, measured consistently
Portals display something like it, but the clock starts on their own listing date, and a relisting resets it. MLS has rules about this; portals do not, so comparing days-on-market across sources produces numbers that look comparable and are not. Tracking the shape of a series over time rather than a single reading is the defence, as in SERP history.
Off-market and coming-soon inventory
Pocket listings, coming-soon status and withdrawn listings are MLS states. A public page shows what a portal chose to publish.
Full commission and broker fields
Compensation, showing instructions, lockbox details: agent-facing MLS fields that no portal renders.
What you do get
Current asking price, physical attributes, the listing agent and brokerage, the agent directory with contact details, and photographs. For lead generation, market monitoring and competitive research, that set is usually sufficient, and it is available today without a licence.
📖 See also Business Entity Search API: Registry Data Without the Portal
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
homes.com/search_properties_for_sale | For-sale listings by market | location | Address, price, beds, baths, sqft, agent, brokerage | Market monitoring | Per call |
homes.com/search_agents | Agent directory, flat | location | Name, phone, brokerage, profile URL | Agent outreach | Per call |
zillow/search_agents | Agent directory, portal shape | location | Card model with reviews and top-agent flag | Reputation signals | Per call |
zillow/search_homes_for_sale | For-sale listings, second source | Location | Zillow's listing model | Cross-checking coverage | Per call |
loopnet/search_listings | Commercial property | location, transaction_type, price and acreage bounds | Commercial listings | Commercial, not residential | Per call |
Every row was verified with monid inspect on 2026-09-02. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.
The commercial row is worth separating out. Commercial property is a different market with different sources, and pointing a residential endpoint at it returns nothing useful. That endpoint was also the one returning 502s on the day of writing, so treat the row as "the right shape for the job" rather than a recommendation to build on it this week.
When do you actually need real MLS access?
Four cases, and in all four the answer is to get licensed rather than to work around it.
You are building for agents. A tool agents use inside their workflow needs the data they see, including compensation and showing fields. Partner with a brokerage.
You are pricing property. Automated valuation without sold comparables is guesswork with a confident interface. Sold data is the input, and it is MLS or a licensed aggregator.
You are redistributing listings publicly. Displaying listings on your own site is exactly what IDX rules govern, and doing it from scraped data is a licensing problem rather than a technical one.
You need completeness guarantees. If a missing listing is a customer incident, you need the feed with a contract behind it.
And the disclosure: this is Monid's blog and we sell per-call access to the public sources described here, including the one that returned 502s today. We do not sell MLS access and cannot get it for you. The four cases above are cases where you should not buy from us, and the gap list two sections up is the honest limit of what the workaround covers.
Conclusion
There is no MLS API you can sign up for, because an MLS is a licensed member association rather than a product. What there is: public portal data that carries current asking prices with the listing agent attached, and agent directories that carry phone numbers.
What the measurement on 2026-09-02 adds is that "the same data from two portals" is not a thing. One agent search returned 48 flat contact rows with phone numbers; the other returned 15 UI cards carrying review information and a top-agent flag. Pick by which question you are answering, and expect to use both if you are answering two.
The gap that does not close is sold prices and days-on-market measured consistently. If your product depends on either, the workaround is not a workaround and the licensed route is the only route.
Free next step: run monid discover -q "real estate property listings" and read the field lists before you write any parsing code. It costs nothing, and the field list is the thing that decides whether a source answers your question. Start at monid.ai.
FAQ
What is the difference between IDX, RESO Web API and an MLS grid?
IDX is the rule set governing how brokers display each other's listings on public websites, so it is a licensing framework rather than a format. The RESO Web API is the modern technical standard most MLSs now expose, replacing the older RETS protocol, and it defines a common field dictionary so a vendor can integrate once rather than per MLS. An MLS grid is a service that aggregates many MLS feeds behind one contract. All three still require you to be licensed or sponsored; they change how painful the integration is, not who is allowed to do it.
Can you republish listing data you pulled from a portal?
Displaying listings publicly is the specific activity IDX rules exist to govern, and doing it from portal data rather than a licensed feed puts you on the wrong side of both the portal's terms and the brokers' agreements. Internal analysis, market research and lead generation are a different posture from publishing a search interface. If your plan is a consumer-facing listing site, treat the licence as a product requirement rather than a legal detail to sort out later.
Where can you get sold prices if not from the MLS?
County recorder and assessor offices, which is where deeds are filed, and this is genuinely public in most of the country. The catch is that it is per-county, arrives with a lag of weeks, and around a dozen non-disclosure states do not publish the sale price at all. Commercial aggregators exist precisely because stitching thousands of county sources together is unpleasant work. For any product that prices property, budget for this properly rather than expecting a portal to supply it.
How often should you re-pull listing data?
Split the pull by how fast the field moves, the same reasoning as the Amazon guide. Price and status change often enough on active listings to justify daily; address, square footage and photographs essentially never change and re-pulling them daily is paying repeatedly for the same bytes. Agent directories move slowest of all, so a monthly refresh is usually plenty, and it keeps the cost of an outreach list nearly flat. Track a per-market row count over time as well, because a sudden drop is a source problem rather than a market event.
Last updated September 2026.
