MLS Real Estate API: Get Listing Data Without MLS Access

Get agents and property details for a market without an MLS membership. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to pull the first page of real estate agents Zillow lists for Austin, TX, then pull the property details for Zillow property 29505949, and tell me which fields came back empty.

One prompt pulls agents and a property record. 1 min setup · 15-25 hrs saved.

Almost everyone who searches for an MLS API is going to be told no: MLS data sits behind a licence, a broker and a signed agreement, and none of that is for sale as an API key. That answer is correct and useless on its own. This guide covers what you can get instead, with the calls run on 2026-10-16: an agent directory and a property record from public sources, what came back in each and what did not, and the gaps that only a licensed feed closes. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

Is there an MLS API, and what is the easiest way to get listing data without one?

There is no MLS API you can sign up for, and the easiest way around that is Monid. Install it once, add a key, and your agent calls public real estate sources for agent directories and property details, with no brokerage, no data agreement and no vendor account.

• Pay per call. Each call is billed on its own: $0.01 for the Zillow agent search and $0.01 for a property record (Verified 2026-10-16 on the real estate tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every API. The same key and the same balance call the real estate endpoints and every other tool on Monid, so a market study that also needs Google Maps or Yelp data does not mean a new account.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tools are there whenever your agent needs them, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

An MLS is a regional database owned by a member association of brokers. There are hundreds of them in the US, each with its own contract, field conventions and approval process, and no national one. Access goes to licensed agents and brokers, and to vendors those brokers sponsor. If you are building a product for agents, your route is partnering with a brokerage. If you are not, no amount of shopping produces MLS credentials, and the useful question becomes which of the things you wanted from MLS are on public pages.

📖 See also Is There an API for PitchBook Data?

How do you get listings and agents for a market without MLS access?

You search public listing sources by city and read the typed JSON that comes back, one call per page. Most people asking for an MLS API want one of two things, current asking prices in a market or the people working it, and both sit on public pages.

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

Pull the agents working a market

monid run -p zillow -e /search_agents --query '{"location": "Austin, TX"}'

The call we ran on 2026-10-16 returned 15 agents on page 1 and a total of 17,211 for Austin, in 3.6 seconds. Pass page to move through them.

Pull one property record

monid run -p zillow -e /get_property_details --query '{"zpid": "29505949"}'

The input is a Zillow property id. It returned an Austin house at $425,000 (Verified 2026-10-16) with bedrooms, bathrooms, living area, year built, coordinates and a description. The Zillow API guide walks the same endpoint field by field, so this guide stays on what the public record leaves out.

Or hand the whole job to an agent

Can you scrape the listing portals yourself with Python?

Yes, people do it, and it works until the page changes. A listing portal is built for people with browsers, so a scraper of your own needs a proxy or browser setup, parsing code, retries, paging and a repair every time the markup or the blocking changes. Setting that up takes hours before the first useful row, and a market study that runs monthly inherits the upkeep.

The rules side differs by country, by state and by how you use the data. Reading listings for internal analysis is a different act from republishing them on a search site of your own, and the second is what licensing regimes exist to govern. Look up the rules that apply where you operate; is web scraping legal sets out how the law treats public pages in general.

Set against that, a call costs $0.01 (Verified 2026-10-16) and returns typed JSON instead of HTML you parse. Pick Monid for anything you will run more than once: the collection is maintained for you, so a page change is not your repair.

What does public listing data carry, and what does it leave out?

It carries the listing as a shopper sees it, and it leaves out the parts of the record that only members see. We ran the property endpoint on two homes on 2026-10-16, and the two records differ in exactly the places that matter if you are comparing this with MLS.

What came back

Both records returned the address, price, bedrooms, bathrooms, living area, lot size, year built, home type, coordinates, a long description, homeStatus and a resoFacts block with parking and lot details. Both carried a homeStatus of FOR_SALE.

What came back empty

{ "zpid": 29505949,
  "price": 425000,
  "zestimate": null,
  "rentZestimate": null,
  "county": null,
  "taxHistory": null,
  "daysOnZillow": null,
  "priceHistory": [ { "date": "2026-08-19", "price": 425000 }, "…" ] }

For the Austin house, zestimate, rentZestimate, county, taxHistory and daysOnZillow were all null. The Boise house, zpid 79594498, returned a zestimate of $570,000 and a rentZestimate of $2,634 (Verified 2026-10-16), and null for county, taxHistory, daysOnZillow and priceHistory. Two records from one endpoint on one day filled different fields, so a pipeline cannot assume a field exists because the schema lists it.

What the price history is, and is not

The Austin house returned 16 priceHistory entries. Each entry has a date and a price and nothing else: no field says whether a row is a listing, a price cut or a sale. Four of the 16 had a price of null. The most recent three read $439,000 on 2026-06-18, $429,900 on 2026-07-10 and $425,000 on 2026-08-19 (Verified 2026-10-16), which is a listing being marked down. Older rows might be sales, but the row cannot tell you. An MLS record separates those events with explicit status and sold-price fields, and that is the single biggest difference you will feel.

The agent side

The Zillow agent directory returned 15 cards for Austin, each shaped like this, trimmed:

{
  "__typename": "AgentDirectoryFinderProfileResultsCard",
  "cardActionLink": "https://www.zillow.com/profile/Realty%20Austin",
  "cardTitle": "Realty Austin Compass",
  "isTopAgent": false,
  "profileData": [
    { "formattedData": "$17K - $5M", "label": "team price range" },
    { "formattedData": "267", "label": "team sales last 12 months" },
    { "formattedData": "11,856", "label": "team sales in Austin" }
  ],
  "reviewInformation": { "reviewAverage": 5, "reviewCount": 3135 },
  "tags": [ { "text": "TEAM" } ]
}

It is a display card rather than a contact record. It carries a profile link, a price range, sales counts and a review average and count, and it has no phone number and no email field. Five of the 15 cards had isTopAgent set, and 11 carried a TEAM tag, so a row is often a team and not a person. That makes it a good fit for ranking and reputation work, such as who sells the most in a market, and a poor fit for outreach unless you follow cardActionLink to a profile.

What goes wrong when you build on public listing data?

Four things hide until you run more than one market. The first three came out of our calls on 2026-10-16.

Why is an empty field not the same as zero?

Because null means the portal did not show it, and an average that treats it as 0 is wrong. On the Austin record zestimate was null, and on the Boise record it was a number. If you compute a median across a market, drop the rows with null and report how many you dropped, or the number reads as a market when it is a sample.

const priced = rows.filter(r => r.zestimate != null);
const dropped = rows.length - priced.length;   // report this next to the median

Why does a price history not give you sold prices?

Because the rows carry a date and a price and no event type. If your product prices property, reading a row as a sale is a guess. Treat priceHistory as the asking-price trail it plainly is, and source sold data separately (see the FAQ).

Why do two portals not return the same agent shape?

Because each returns its own page model. The Zillow agent search returns a display card with review data and sales counts, which is what that product shows on its agent finder. Another portal's directory will carry other fields. Treat each source as its own schema and keep a column per provider.

How many calls is a whole market?

For Austin, 1,148. The agent search said 17,211 agents found and returned 15 on page 1, so walking the directory at 15 a page is 17,211 / 15 rounded up, or 1,148 calls. At $0.01 a call (Verified 2026-10-16) that is about $11.48. Decide whether you want all of them before you start; for most jobs the first page or two, which hold the highest-ranked cards, answer the question.

Which status should you read first?

Read the status field in inspect and discover. On 2026-10-16 inspect listed the Zillow agent search as degraded with a median run time of 121,825 ms, and the call returned in 3.6 seconds. Status describes recent history, not your call, so it is a prompt to log latency and retries rather than a verdict.

Which endpoint should I use for which job?

Per-call prices, Verified 2026-10-16 with monid inspect: agent search $0.01, property details $0.01, homes for sale $0.05, recently sold $0.05. We ran the first two endpoints for this guide. The two search endpoints at $0.05 a call were inspected and not run, so the fields in their rows come from their endpoint descriptions rather than from our calls. The recently sold endpoint is the one to look at if sale prices are your gap, because its description lists sold price and sale date. Market-level searches at $0.05 a call add up faster than the $0.01 ones, so size the loop before you start it. Current figures are on monid.ai/tools.

When is another route a better fit?

Four cases, and in all four the answer is to get licensed rather than work around it.

You are building for agents. A tool agents use inside their workflow needs the data they see, including compensation and showing instructions. Partner with a brokerage and take the feed.

You are pricing property at scale. Automated valuation needs sold comparables with an explicit event type, and the price history we pulled had none. Sold data comes from MLS, county records or a licensed aggregator.

You are republishing listings. Displaying listings on your own site is what IDX rules govern, and rules differ by MLS and by state. Check the ones that apply to you before you build a consumer search page.

You need a completeness guarantee. If a missing listing is a customer incident, you need a feed with a contract behind it, and a pay-per-call endpoint is not that.

And the disclosure: this is the Monid blog and we sell per-call access to the public sources described here. We do not sell MLS access and cannot get it for you.

Conclusion

There is no MLS API you can sign up for, because an MLS is a member association and not a product. What you can get without one, in one prompt through Monid, is an agent directory at $0.01 a call and a property record at $0.01 a call (Verified 2026-10-16), ready inside your agent whenever you need them.

Two things matter more than the choice of source. A field that exists in the schema is not a field that is filled: the two homes we pulled came back with different parts of the record empty. And a price history of dates and prices is an asking-price trail, not a record of sales, so decide early whether your product needs sold data and where it will come from.

How we estimated the time saved: building and running your own listing-detail scraper and your own agent-directory scraper is roughly 8 to 12 hours each for getting past blocking, parsing typed rows with paging, and the first month of upkeep, which is 16 to 24 hours, rounded to 15 to 25. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid discover -q "real estate agents", monid inspect -p zillow -e /search_agents, make one call, and count which fields are null in what comes back.

FAQ

Published September 2026.