Is There a Zoopla API? How to Get Zoopla Data in 2026

Search zoopla api and the first page of results is remarkably encouraging. A GitHub project with 89 stars promising "hyper local data on 27m homes, over 1m sale and rental listings, and 15 years of sold price data." An API directory entry with docs and auth details. A Python package on PyPI. A tutorial walking you through building a property app on top of it. Register for an account, apply for an instant key, start querying.

So you point your terminal at developer.zoopla.co.uk. And curl refuses to connect:

curl: (60) SSL: no alternative certificate subject name matches
target host name 'developer.zoopla.co.uk'

The hostname still resolves. It just serves a certificate issued for a different domain, so every modern HTTP client aborts before it even sees a status code. Force past the certificate with -k and you get a 404. That's the real state of Zoopla's developer programme in 2026, and no page ranking for the query will tell you.

The short answer

No. Zoopla has no public API any more. There is no developer portal, no key to apply for, no sandbox, and no sunset notice explaining where it went.

What makes Zoopla different from every other portal in this series is that its API was real. StreetEasy never shipped one. Rightmove's APIs exist but only ever accepted data. Zoopla's genuinely worked: developers registered, got keys, and built things. Then it was left to rot with the documentation still up. Every stale tutorial ranking today isn't lying about the past, only about the present.

Below: what actually happened, the three official doors that still exist (none of which is an API key), and the hosted endpoints you can call this afternoon.

What actually happened to Zoopla's API

There was no announcement, so the timeline has to be read off the artifacts developers left behind. It's a fairly clear archaeological record.

The most popular Python client, the zoopla package on PyPI, shipped steadily from September 2016 through to version 1.0.0 on 6 October 2018. Nothing since. Its repository was last pushed in September 2021, and every issue filed after 2020 is a Dependabot or Snyk security bump. Nobody has opened an issue saying "the API stopped working," which tells you something bleaker than an angry thread would: by then nobody was still calling it.

By July 2020, a developer building a UK property tool had added an update to the top of their own tutorial warning readers that Zoopla no longer actively supported the API and that keys would randomly stop working with no warning. Not revoked. Just… unreliable, then gone.

Leaving the docs up is the worst way to close an API. A hard 410 with a farewell blog post costs a developer ten minutes. A portal that half-exists costs them an afternoon, and it keeps costing new developers that afternoon for years, because search engines have no idea the service died. Six years on, the top results for the query still send people to a login page whose certificate expired out from under it.

As for why: listings are the moat, and portals guard the moat. Zoopla now sits inside Houseful alongside Hometrack and the Alto agent software business, and property data monetisation moved decisively upmarket, from free developer keys to enterprise contracts. Which brings us to the doors that are still open.

The three official doors that do exist

"Zoopla has no API" is shorthand. Zoopla Group ships plenty of APIs. None of them do what you want, and it's worth knowing exactly why before you spend a week trying to get into one.

Real-Time Listings: push, not pull

Zoopla's member-facing integration is the Real-Time Listings service. Agency software (Alto, Jupix, Expert Agent and friends) and feed specialists use it to send listings to Zoopla, and setting one up requires a signed certificate issued by Zoopla for authentication. The archived PHP client for it is blunt about who can use it: partners with access, using credentials they obtain from Zoopla directly.

The direction of travel is the whole story. This API publishes your inventory. It does not read anyone else's. If you're an agent or a CRM vendor, it's exactly the right integration. If you want to know what's for sale in Hampstead, it's useless.

Hometrack: the enterprise door

Zoopla bought Hometrack, the UK's best-known automated valuation business, for £120m in 2017. It now sits beside Zoopla under Houseful, and by its own account contributes valuation data, risk insights or decisioning technology to nearly all of the 1.4 million mortgage approvals processed annually in the UK.

So there is a commercial route to Zoopla-group property intelligence. It's a lender-facing product with a sales cycle, a contract, and an onboarding, aimed at mortgage risk teams rather than developers. If you're building a lending product, start there. If you wanted a key in five minutes, that door has a receptionist.

Research data: free, official, and probably not for you

Here's the one almost nobody writes about. The Urban Big Data Centre at the University of Glasgow has held Zoopla listings data under a partnership with the company since 2016, funded by the ESRC. The Generation 2 dataset covers listings from 1 October 2016 onwards with coordinates attached, and tracks how a listing's features change across its life on the market. Sales and rentals, prices, dates, property characteristics. Real Zoopla data, obtained properly.

Two catches, and they're decisive. Access is limited to UK-based academics conducting non-commercial research, subject to an application and an end user licence agreement. And that licence specifically prohibits using the data to develop house price or rental indices as the basis for commercial products, or to build property valuation tools or other forms of property technology.

Read that twice if you're a founder. It is the perfect dataset for a housing policy paper and explicitly the wrong one for your startup. Worth knowing it exists, worth not wasting a week applying.

Your real options in 2026

Every remaining path to Zoopla listing data trades money against engineering time against fragility. The honest comparison:

Option	Pricing	Setup effort	Where it hurts
Official public Zoopla API	Doesn't exist	n/a	Portal fails certificate validation; forcing past it returns 404. The tutorials ranking for it describe a service that stopped working years ago.
Real-Time Listings / Hometrack	Partner or enterprise contract	Weeks of commercial process	One pushes your listings in, the other sells valuation data to lenders. Neither reads Zoopla's live listing set on your behalf.
UBDC research dataset	Free	An application and a licence	UK academics only, non-commercial, and the licence bars building proptech or commercial indices from it.
DIY scraper	"Free," plus residential proxies and your time	Days to build, indefinitely to maintain	Zoopla sits behind a managed Cloudflare challenge; even robots.txt returns an interstitial to a plain client. Every layout change becomes your Tuesday.
Scraper marketplace actors	Roughly $5 to $7 per 1,000 results	Hours	Residential proxies required by default. You still own schema, dedup, retries and monitoring, and several Zoopla actors on Apify are already marked deprecated.
Hosted REST endpoints (RealtyAPI)	Free tier of 250 requests/month; paid plans from $20/month for 20,000 requests	Minutes	UK coverage only, and the address-based endpoints need a full postcode to resolve.

We've written up the general shape of this decision in web scraping vs. using an API. Short version: scraping wins when the data has no API at any price and your volume is genuinely tiny. It loses the moment uptime matters or somebody else depends on your output.

Is scraping Zoopla legal?

Worth being precise here, because the UK answer differs from the American one people usually quote.

Zoopla's terms of use carry a section headed "No text or data mining, or web scraping," under which you shall not conduct, facilitate, authorise or permit any text or data mining or web scraping in relation to the site, and may not use any robot, bot, spider or scraper to access, copy, monitor or republish any part of it. That is not ambiguous drafting. The US hiQ line of cases about publicly visible data doesn't transplant neatly to a British portal with terms like these.

The UK's copyright framework does contain a text and data mining exception, but section 29A of the CDPA covers non-commercial research only, which is precisely why the official Zoopla research dataset takes the shape it does. Building a commercial product sits outside it.

We go through the wider landscape in is website scraping legal? and explain our own sourcing position in is RealtyAPI legal?. The practical read hasn't changed: the legal exposure is real but arguable, while the engineering pain is certain. Most teams don't abandon scraping because a solicitor called. They abandon it because of maintenance.

What RealtyAPI's Zoopla endpoints cover

RealtyAPI runs hosted Zoopla endpoints as part of its real estate data platform. You call a normal REST endpoint with an API key; proxies, challenges and parsing stop being your problem. Nineteen endpoints across four groups:

Group	Endpoints	What they're for
Search	/autocomplete, /search/bylocation, /search/byzip, /search/bycoordinates, /search/byurl	Find listings by place name, postcode, lat/lon radius, or by pasting a Zoopla search URL whose filters get replicated as-is
Details	/details/byid, /details/byurl, /details/byaddress	One full record, addressed by listing id, listing URL, or a UK street address
Property data	/pricehistory, /images, /poi, /history, /estimates, /sold-prices, /ev-charging	Individual slices: price changes, photos and floor plans, nearby amenities and transport, historic listings and sales, valuations, Land Registry sold prices, and EV chargers
Agents	/agent/search, /agent/details, /agent/forsaleproperties, /agent/forrentproperties	Estate agent branches, their contact details and memberships, and full pages of their current stock

The filters that make it feel British

This is where generic national listing APIs quietly fail UK products. They give you beds, baths and price, then leave you unable to express how anyone in Britain actually shops for a house. The search endpoints take the Zoopla-native filters:

• tenure: freehold, leasehold, or share_of_freehold. The single most requested filter in UK property software and the one US-built APIs never have, because the concept barely exists there.
• newHomes: true to include new builds, false to exclude them, only for new builds alone
• chainFree: no onward chain, which is how buyers filter when they need to move by a date
• sharedOwnership and retirement: two whole market segments most schemas can't represent
• auction: auction lots only
• includeSold: pull sold-STC and under-offer listings alongside live ones
• Rentals get their own set: furnished, petsAllowed, billsIncluded, sharedLiving, studentHousing
• priceRange, bedsRange, bathsRange and sizeSqftRange all take the same min:/max: syntax, so min:500000,max:750000 works the way you'd guess
• keywords: free text matched against listing descriptions, for the things that never became structured fields ("garden", "period features", "parking")

Put those together and "chain-free freehold house, no new builds, under £600k, with a garden" is one query rather than a post-filtering pipeline over everything in the postcode.

Why there are so many small endpoints

Five of the property-data endpoints return one slice each rather than a whole record: /pricehistory gives the price-change timeline, /images gives photos and floor plans, /poi gives points of interest and transport links, /estimates gives a sale estimate and rent estimate, and /ev-charging gives nearby chargers.

That's deliberate, and the reason is billing rather than aesthetics. If you're rendering a photo gallery you don't need transport links; if you're drawing a price-drop sparkline you don't need forty images. A request is a request either way, so being able to ask for the slice you're about to render keeps your credit burn proportional to what you actually display.

Quick-start: UK listings in three requests

Base URL: https://zoopla.realtyapi.io. Auth: your key in the x-realtyapi-key header. The free tier is 250 requests a month, which is plenty to work out whether the shapes fit your product, and the docs cover key setup in a couple of minutes.

1. Resolve the location

Zoopla searches by its own internal area slugs, not by whatever string a user typed. /autocomplete is the same suggestion service behind the search box on the site:

curl "https://zoopla.realtyapi.io/autocomplete?input=Hampstead&limit=10" \
  -H "x-realtyapi-key: YOUR_KEY"

You get back ranked suggestions covering neighbourhoods, towns, postcodes, counties and regions, each carrying the slug Zoopla uses internally. Feed the displayName straight into search. Skipping this step is the most common reason a first integration returns nothing: a string that looks obviously correct to a human is not necessarily an area Zoopla recognises.

2. Search

curl "https://zoopla.realtyapi.io/search/bylocation?location=Hampstead,%20London&searchType=For_Sale&priceRange=min:500000,max:1500000&bedsRange=min:2&tenure=freehold&chainFree=true&sortOrder=Most_Reduced" \
  -H "x-realtyapi-key: YOUR_KEY"

Results come back 25 to a page, which is Zoopla's own fixed page size, each carrying a listingId, address, photos, price, beds and baths, property type, tenure, listing date and the estate agent branch behind it. The response includes a nextPage boolean; keep paging until it's false. radius defaults to one mile and takes fractional values, so radius=0.25 gets you genuinely local results rather than half a borough.

That sortOrder=Most_Reduced is worth noticing. Sorting by biggest price drop is a motivated-seller feed with no extra work on your side.

3. Fetch the full record

curl "https://zoopla.realtyapi.io/details/byid?listingId=72743732" \
  -H "x-realtyapi-key: YOUR_KEY"

The listingId is just the trailing digits of a Zoopla listing URL, so zoopla.co.uk/for-sale/details/72743732/ gives you 72743732. If you're starting from URLs you've collected elsewhere, /details/byurl does that extraction for you and takes the whole URL.

A production-ish loop

Same flow with pagination and the error handling you actually want, because anything fronting live web data will occasionally have a bad minute upstream:

import requests

BASE = "https://zoopla.realtyapi.io"
HEADERS = {"x-realtyapi-key": "YOUR_KEY"}

def get(path, **params):
    r = requests.get(BASE + path, params=params, headers=HEADERS, timeout=60)
    r.raise_for_status()
    return r.json()

def resolve_location(query):
    """Turn user input into something Zoopla actually recognises."""
    data = get("/autocomplete", input=query, limit=5)
    suggestions = data.get("suggestions") or data.get("results") or []
    if not suggestions:
        raise ValueError(f"No Zoopla area matches {query!r}")
    return suggestions[0]

def search(location, **filters):
    page = 1
    while True:
        data = get("/search/bylocation", location=location, page=page, **filters)
        results = data.get("results") or []
        if not results:
            break
        for listing in results:
            yield listing
        if not data.get("nextPage"):
            break
        page += 1

area = resolve_location("Hampstead")
print("searching:", area)

seen = set()
for listing in search("Hampstead, London", searchType="For_Sale",
                      priceRange="min:500000,max:1500000",
                      tenure="freehold", chainFree="true"):
    listing_id = listing.get("listingId")
    if listing_id in seen:      # branches occasionally list twice
        continue
    seen.add(listing_id)
    print(listing_id, listing.get("price"), listing.get("address"))

print(f"{len(seen)} unique listings")

Wrap that in a cron job, diff the listingId set against yesterday's, and you have new-to-market alerts. Diff prices instead and you have reduction alerts. The point of an API over a scraper is that this loop is the entire integration; there's no proxy pool underneath it waiting to be babysat.

The address route: UPRNs, sold prices, and estimates

Everything above starts from a search. There's a second way in that matters more than it sounds, and it's the part of the UK data model that catches people out.

If you already know an address, /details/byaddress resolves it to a UPRN, the Unique Property Reference Number that identifies every addressable location in Great Britain, and returns the property record: historic listings, sold-price history, sale and rent estimates, plus the live listing if there is one. /history and /estimates take the same address (or a UPRN directly, skipping resolution) and return just their slice.

The catch is non-negotiable and worth putting in your validation layer today: a full postcode is mandatory. Zoopla's address resolver returns nothing for "12 Mansfield Road, London." It needs "10 Mansfield Road, NW3 2HN." If your app collects addresses from users, capture the postcode as a separate required field rather than parsing it back out of a free-text line later.

Why bother with UPRNs at all? Because an address string is a terrible join key and a UPRN is a good one. "Flat 2, 14 High St" and "14A High Street" may be the same dwelling in two databases; the UPRN is the same number in both. Once you have it, you can hold a stable identity for a property across your own history, EPC data, and Land Registry records without ever fuzzy-matching strings again.

For area-level history rather than a single property, /sold-prices browses the sold-price database that backs the Prices tab in Zoopla's app: Land Registry entries with Zoopla's matching property metadata. It takes exactly one geo selector, and which you pick is a real decision:

• geoId, a slug from /autocomplete such as london/elm-row. Most precise, and the one to default to.
• postcode, forwarded for Zoopla to resolve. Convenient, and results vary depending on whether it maps cleanly onto an area slug.
• lat plus lon for an exact coordinate search.
• bbox as ne_lat,ne_lon,sw_lat,sw_lon, which is what you want when the query is literally "whatever is in the current map viewport."

Add from and to as ISO dates to window the results, propertyType to narrow by build type, and page through with first (up to 100) plus the endCursor from the previous response. Cursor pagination rather than offsets, which is the correct choice for a dataset people page deeply into.

What you still can't get

The honesty section, because a comparison table that only lists other people's limitations isn't a comparison.

These endpoints return what Zoopla holds now: live listings, their details, the sold-price and estimate records attached to a property. /pricehistory covers one listing's life on the market, not the market's. If you want your own longitudinal view of asking prices across a borough, you capture snapshots on a schedule and diff them, which the loop above plus a cron job and a table gets you further towards than you'd expect.

Agent data is what a branch publishes publicly, contact details and memberships and current stock. It is not a lead database, and it shouldn't be treated as one. There's no off-market inventory either; Zoopla shows what agents choose to put on Zoopla, so anything sold quietly between two parties was never in scope. And coverage is Britain, full stop. For anything wider you'd pair this with the other sources on the platform, the same way we've worked through which Rightmove APIs actually exist, whether Redfin has an API, and how the listing APIs compare overall.

Key takeaways

• Zoopla's public API is gone, and the search results haven't caught up. The developer portal fails certificate validation and returns 404 behind it. Every tutorial ranking for "zoopla api" documents a service that stopped being supported around 2020.
• The official APIs that remain point the wrong way. Real-Time Listings pushes an agent's stock into Zoopla under a signed certificate; Hometrack sells valuation and risk data to mortgage lenders. Neither reads listings out for you.
• There is one legitimate free source, and it's for academics. UBDC's Zoopla dataset runs from October 2016, and its licence explicitly bars building valuation tools, proptech, or commercial indices from it. Perfect for research, useless for a product.
• UK-specific filters are the whole game. Tenure, chain-free, shared ownership, retirement and new-build status are how British property is actually searched, and a listings API without them will have you post-filtering forever.
• Capture postcodes as a separate field from day one. Every address-based endpoint resolves through a UPRN and needs a full postcode. Retrofitting that into a schema that stored one free-text address line is a genuinely annoying migration.

If you're building for the UK market, the quickest way to find out whether this data fits is to run the three requests above against your own patch. The free tier's 250 requests is enough to point /autocomplete at your postcode, page a search, and pull one full record, which is the entire integration you'd end up shipping anyway.