A real estate listing API is an HTTP interface your software calls to read listing records (price, status, address, photos, agent and office details) as structured data, usually JSON. In the US, the hard part is rarely the code. It is getting permission from the MLS to use the data, then respecting its display rules. Once you have a feed, a second API can do the publishing: ours creates a website for each new property from your own templates.
This guide covers both halves: how to get authorized listing data, what to check before you build, and how to wire the result into a website workflow.
TL;DR
- A listing API returns listing records as structured data. In the US, access is granted by the MLS or an authorized data platform under a license, not by signing up with a credit card.
- Pick the feed type first (IDX for public display, VOW for signed-in visitors, Private for back-office use). It decides which fields and records you can show.
- Build defensively: read the metadata, paginate, sync incrementally, and remove listings that leave the permitted feed.
- Pulling listing data and publishing a website are two separate jobs. The Yuppsy API and MCP handle the second: a new property in your CRM triggers a new website from your template.
- Plans start at $4.00 per month per single property website, and the first 3 property websites are $0 one-off.
Table of Contents
- What a real estate listing API actually returns
- Two kinds of listing API (and why people mix them up)
- How to get authorized access to US listing data
- What to check before you build
- Building the integration: auth, queries, pagination, sync
- From listing record to live website
- Our perspective: separate the feed from the publishing
- What it costs to publish a site per listing
- Choosing your route
- FAQ
- Sources
What a real estate listing API actually returns
An MLS listings API lets software query listing records over HTTP and get results back, commonly as JSON. Depending on your permissions, the records can include property attributes, price, status, addresses, remarks, photos, virtual tours, agent and office details, and open-house events, according to a data provider's overview of MLS listing access. The same overview lists the common resources as Property, Media, Member, Office and OpenHouse, and warns that the fields you see depend on your license.
Where does that data come from? RESO, the industry standards body, describes the chain: the owner works with a listing agent, the listing broker submits the listing to the MLS, and the MLS distributes it through interfaces, apps and API feeds. It includes fields and media such as photos, videos, floor plans and documents, and often sold and leased transaction data.
Two practical consequences follow:
- Fields are not universal. Each MLS decides what it exposes. Do not design around a schema you saw in one market.
- Unlisted properties are a different problem. An MLS feed covers listed properties. Off-market homes generally need public-record or other data sources.
Two kinds of listing API (and why people mix them up)
When readers search for a property listing API, they usually mean one of two things.
| Listing data API | Website creation API | |
|---|---|---|
| What it does | Supplies listing records: price, status, photos, agents | Builds and manages the website that presents a property |
| Who grants access | The MLS or an authorized data platform | The website platform you subscribe to |
| Main constraint | Licensing, display rules, data freshness | Templates, content, publishing workflow |
| Typical user | Brokerage developer, vendor | Agency, agent, CRM admin |
Most agencies need both. The first gives you the facts about a home. The second turns those facts into a page a buyer can open, share and bookmark. Confusing them is why projects stall: teams spend weeks on a feed and then discover nobody has decided how each listing becomes a site.
How to get authorized access to US listing data
Access is market- and agreement-specific, not something any developer can switch on. Spark's access guide lays out the usual path:
- Identify the MLS or authorized data platform that covers your market.
- Identify the brokerage participant and the intended product.
- Choose the feed type: IDX, VOW, Private or another.
- Submit the application and licensing agreement, describing your users and how you will use the data.
- Wait for MLS approval and credentials.
The feed types matter more than they look. Spark's guide separates IDX (public listing display), Private (member-only or back-office use) and VOW (visitors who create accounts and sign in). A public single-property website normally sits in IDX territory, while an internal CRM sync may be Private.
What the MLS will ask you
Expect questions about who operates the software, who sees the data, and where it is displayed. One access guide for software products recommends documenting the brokerage participant, software operator, audiences, surfaces, alerts, apps, exports, stored media and sold records before you ask. Having that written down shortens the back-and-forth.
Two layers of authorization
Spark documents two authorization layers: the developer's and the MLS member's (or end user's). IDX requests carry an access token showing the member authorized the application, and OAuth 2 means developers never store member passwords. The same API supports CRM applications and returns data according to the user's role and permissions. The logic is simple: both the software provider and the participating member must be identifiable.
Costs and who can apply
Rules differ by MLS. UtahRealEstate.com says API access requires registration and a data-licensing agreement, and eligible users include approved vendors and technically capable brokers, brokerage employees and supervised agents. Georgia's FMLS requires third-party vendors to use its marketplace and Bridge platform and submit products for approval. It states a $250 application fee for vendors, waived for member brokerages using the data in their own brokerage products. Other feeds are described as invite-only and subject to individual MLS partners, in the US and Canada.
If you are a brokerage, ask your MLS first whether you can get the feed directly as a member. It is often the cheapest and fastest route.
What to check before you build
The expensive mistakes happen before the first request. Check these with the MLS or platform, in writing.
- Approved feed type and fields. Paragon's documentation says to verify the approved feed, available fields and records, and conditional field suppression. Its metadata endpoint shows what was granted for each dataset.
- Replication and onward sharing. Can you store a copy? May the broker share access with a third party, such as a website vendor? The same documentation says replication and third-party sharing depend on MLS approval.
- Permitted use. UtahRealEstate.com states that data must be limited to the product described in your license and not used for other internal or external purposes unless expressly authorized.
- Display rules. Spark's listings documentation says each MLS defines its own display rules, and that visibility, editability, searchability and labels vary by user and property type. Read the metadata instead of assuming.
- What happens when sharing ends. RESO says data-share agreements should specify whether data can be used only inside the MLS, in CMA reports, on public IDX or VOW sites, after sale, and what happens when the arrangement ends.
- Real behavior. Test attribution, missing addresses, missing photos, status changes and the removal of listings that leave the permitted feed, as the access guide above recommends.
Commercial APIs add controls on top. One large portal's terms limit access to approved licensees and sites, require an issued identifier on calls, prohibit bulk access and keeping copies, and require branding and disclaimers. The same terms state a default of 1,000 daily calls for two of its APIs, with higher limits possible after review. Credentials do not end the compliance work.
Building the integration: auth, queries, pagination, sync
Most modern MLS access is built on the RESO Web API, an OData-style interface. Paragon recommends it over RETS because it follows current industry standards. Requests need a dataset code, a resource, an access token and query parameters over HTTPS.
Authentication
Use the token you were issued and send it in an Authorization header. Paragon recommends the Server token for server-to-server requests, so keep it out of browser code.
Query only what you need
A RESO Web API integration guide describes the standard OData controls: filter, select, top, orderby and expand. Select only the fields you will display. Smaller payloads are faster and easier to keep inside your license.
Pagination
Page size is set by each MLS. The same guide says subsequent pages are supplied through the @odata.nextLink value, so follow that link rather than computing offsets yourself.
Keep data fresh without hammering the API
The recommended pattern is one initial full pull, then incremental requests filtered on ModificationTimestamp. Add a separate purge process to remove records that are no longer present. Without the purge step, sold or withdrawn listings linger on your sites, which is both embarrassing and often a rules violation.
Be defensive
Providers can change restrictions and field payloads. Paragon recommends defensive programming: handle missing fields, unexpected values and error responses, and respect documented rate limits. Log every failed call so someone notices before a client does.
From listing record to live website
Once a listing is in your CRM or property management system, the question is what happens next. Many teams still hand it to a person: copy the details, pick a layout, upload photos, publish. That works at five listings and breaks at fifty.
This is the gap our API and MCP fill. Your workflow triggers Yuppsy when a new property is added, and we generate a dedicated website from the website model and template you chose in advance. The flow looks like this:
- A realtor adds a listing to your CRM, database or property management platform.
- Your automation calls the Yuppsy API, or an AI agent connected through Yuppsy MCP does it.
- Property information fills the template and website model you selected.
- The generated site goes into your publishing workflow.
MCP, the Model Context Protocol, is an open-source standard for connecting AI applications to external systems, and assistants such as Claude and ChatGPT support it. For you, that means a compatible AI agent can take an instruction like "publish a site for the new listing on Maple Street" and carry it out through Yuppsy, without anyone writing glue code. The API suits developers who want a direct connection from a CRM or internal tool. MCP suits teams building agent-driven workflows.
The licensing rules above still apply to what you put on the site. Use only listing content your feed type allows for public display, and keep the attribution the MLS requires in your template. If you want the background on why a dedicated page per listing works, our guide to the single property website covers it, and the piece on property management automation shows what else is worth automating first.
Our perspective: separate the feed from the publishing
We see the same pattern in agencies that try to automate listing websites. They treat "get the data" and "publish the site" as one project, and the licensing questions swallow the schedule. Our advice is to split them.
First, settle your data path with the MLS: feed type, fields, display rules, who may touch the data. This is slow and mostly paperwork. Meanwhile, set up the publishing side: choose your website models, define the brand look once, and let a trigger create sites from a record in your CRM. Predefined models are what keep fifty listing sites looking like one company instead of fifty experiments.
We also think the next step is agents, not more dashboards. If an AI agent already works inside your CRM, giving it a way to create and manage property websites through MCP removes a manual handoff. The agent should still operate inside the same permissions and display rules a person would. Automation that ignores the license is a liability, not a saving.
— roberto scutaru
What it costs to publish a site per listing
Our plans are priced by what you publish, and the entry is free to try. All amounts below are per month unless noted, as published on our pricing page.
| Plan | What you get | Price |
|---|---|---|
| Free entry | 3 property websites | $0 one-off |
| Single Property website | One listing site | $4.00 per month |
| Agent website | A personal agent site | $6.00 per month |
| Company website | An agency site | $10.00 per month |
| Silver | 1 company, 3 agents, 10 properties | $60 per month |
| Gold | 1 company, 10 agents, 30 properties | $180 per month |
| Platinum | 1 company, 20 agents, 60 properties | $350 per month |
Storage for photos and media is separate: Tier 1 (500 MB) is $15.00 per month, Tier 2 (1 GB) is $25.00 per month and Tier 3 (2GB) is $45.00 per month. If you are wiring up a workflow, start on the free tier with a test listing, then pick the bundle that matches your portfolio. You can see everything on the Yuppsy pricing page, or look at the Yuppsy platform first.
Choosing your route
- You are a brokerage with MLS membership: request the feed directly, confirm that a website vendor may receive or display the data, and keep CRM sync as Private use if that is what your license says.
- You are an independent developer or vendor: expect an application, a license, possibly a fee, and an approval of your product before launch.
- You mainly need listing pages, not a data product: start from your CRM records and a template-driven site builder. Add a feed later, when you know which fields you need.
- You want buyer traffic from those pages: see our list of buyer lead tactics for what to do once the site exists.
FAQ
Is there a free real estate listing API?
There are free tiers and free sample data on some platforms, but full MLS listing data is licensed. Access depends on the MLS, the feed type and your agreement, and some MLSs charge vendors an application fee. Public-record data is a separate source and does not include active MLS listings.
Can any developer get MLS data through an API?
No. You generally need MLS approval, a brokerage participant behind the product, and a signed license describing how you will use the data. Some feeds are invite-only and tied to individual MLS partners.
What is the difference between IDX, VOW and Private feeds?
IDX is for public display of listings, VOW is for visitors who create accounts and sign in, and Private is for member-only or back-office use. Which one you hold determines what you can show on a public website.
Can a listing API build a website for me?
A data API only returns records. Building the page is a separate job. With the Yuppsy API or MCP, your CRM or an AI agent triggers website creation from your chosen template whenever a new property is added.
How often should I refresh listing data?
Do one full pull, then request incremental changes filtered on ModificationTimestamp, and run a purge to remove records that have left the feed. Follow your MLS's rate limits and any rules about how fresh displayed data must be.
Sources
- MLS Listings API: How to Access MLS Listing Data
- Real Estate Data Sharing and Alignment, RESO
- How to Set Up API Access, Spark
- Spark API overview
- Spark Listings documentation
- UtahRealEstate.com Data Services FAQ
- FMLS Marketplace Info
- MLS Listings, Data & APIs
- Terms of Use, Data & APIs
- Property Information Central API documentation
- How to request MLS data for a software product
- RESO Web API Integration for Your Existing Website
- What is the Model Context Protocol (MCP)?