MLS Feeds vs. Zillow Property Lookups: Choose the Right Data Connection

Two different connections that both get called an API

Developers searching for an MLS API usually want listing data in their application. Two very different connections can deliver some of it. An MLS feed is listing data that a multiple listing service distributes to participants and approved technology vendors under a license. A property lookup takes a property you already know, by link or address, and returns what a public page shows about it.

They differ in what you can ask, what you are allowed to do with the answer, and what you need before you start. Choosing the wrong one is expensive in both directions: a team that needs market-wide inventory cannot build it from lookups, and a team that only needs details for a list of addresses may not need to negotiate feed access at all.

Disclosure: PropertiesAPI sells the second kind of connection. It does not provide licensed MLS access or an MLS feed. This article explains the distinction and points to the official sources for MLS access so you can judge for yourself.

How MLS feed access works

The Real Estate Standards Organization, RESO, maintains the standards most modern MLS feeds use. The RESO Web API is a transport standard built on open web technologies, and the RESO Data Dictionary defines shared field names and meanings so systems can exchange listing data consistently.

A standard is not access. RESO states that access to data from the Web API is gained through local MLSs: the requester agrees to that MLS's data use and licensing policies and receives credentials from the MLS or its technology provider. Each MLS sets its own requirements, and a product that spans several markets typically needs an agreement with each relevant MLS or with a vendor already licensed by them.

Display is governed too. The National Association of Realtors describes IDX as the arrangement under which brokers consent to display each other's listings on participant websites. Requirements for who can receive a feed, what may be shown, and how data must be refreshed or removed come from the MLS and its policies, so read the actual agreement rather than relying on a summary, including this one.

• Compare data categories before choosing a vendor

Decision matrix

Use the matrix to match your requirement to the connection. The MLS column describes the general shape of feed access; the specifics depend on each MLS. The lookup column describes PropertiesAPI as documented today.

When you need an MLS feed

Choose an MLS feed, directly or through a vendor licensed by the MLS, when the product's value depends on knowing about listings the user has not told you about. Property search portals, IDX sites for brokerages, agent tools that alert on new inventory, and market analytics that count every active listing all fall into this group.

In those cases a lookup service is the wrong foundation even if it returns some of the same fields. Discovery is a capability of the feed and its license, and you cannot reconstruct it by looking up addresses one at a time. Building that workaround also risks breaching the terms of whichever source you rely on.

• A searchable map or list of active listings in a market.
• Alerts for newly listed or changed properties.
• Brokerage or agent websites that display other brokers' listings.
• Market statistics that need every listing, not a sample.

When a known-property lookup fits

Choose a lookup when the property is already known and you need its current details: enriching a spreadsheet of addresses, checking a link a user pasted, giving an AI agent a tool to look at one property, or tracking a fixed list over time with your own snapshots. The input names the property; the API does not have to find it.

A lookup returns the listing price and status, Zillow's estimates when shown, facts about the home, photo URLs, price and tax history, schools, and the listing agent and broker as shown on the page. The response also includes mlsId and mlsName when the page shows them. Treat those as labels that identify the listing's origin, not as a credential or a right to use that MLS's data.

Every response says when the page was collected, so your application can describe freshness honestly. Failed lookups are not billed, and repeat lookups inside the cache window reuse the earlier collection.

• Every field in the property response
• Make your first lookup

# A known-property lookup: you supply the property, the API returns its page data.
curl -G "https://api.propertiesapi.com/v1/zillow/property" \
  -H "x-api-key: $PROPERTIESAPI_KEY" \
  --data-urlencode "address=2640 Steiner St, San Francisco, CA 94115"

# Fields worth reading in this comparison (illustrative values):
# data.homeStatus  "FOR_SALE"
# data.price       525000
# data.mlsName     "Example MLS"   <- a label shown on the page
# data.mlsId       "1234567"       <- not credentials for that MLS's feed
# meta.fetched_at  "2026-10-19T14:02:11.000Z"

Using both, carefully

Some products have both needs: a licensed feed for discovery in the markets they serve, and lookups to examine specific properties a user brings from elsewhere. That can be reasonable, but the two data sets come with different terms. Before combining them in one view or one database, check what each agreement allows for display, storage and redistribution.

Keep the source on every record. A field that came from a feed and a field that came from a page lookup can share a name and still mean different things or carry different obligations. Provenance columns make later reviews, takedowns and audits manageable.

Do not use lookups to approximate a feed. Looking up every address in a county on a schedule is a discovery workflow in disguise. It is costly, it will miss listings you had no address for, and it sits outside what a known-property lookup is for. If discovery is the requirement, budget for the licensed route from the start.

• Other ways teams get Zillow data

Questions to ask before you commit

Ask these of any MLS, feed vendor or lookup service, including us. Get the answers in writing and match them against your product's actual workflow, not a demo.

• Which markets and listing types are included, and which are excluded?
• Who is eligible to receive the data, and what approval is required?
• What may be displayed, stored, combined and redistributed, and for how long?
• How are changes, withdrawals and removals delivered, and how quickly must I apply them?
• What exactly is billed: a request, a successful result, or a returned record?
• How does the service report when a value is missing or when data was collected?