Is There a Domain.com.au API? How to Get Listing Data

Ask this question about most property portals and you get a flat no. Ask it about domain.com.au and something unusual happens. A real developer portal loads. You can register with your GitHub account. Thirteen documented API packages are sitting right there, rate limits are published in plain numbers, and there is a service level agreement with a p95 target in it.

So the answer is yes, and you can stop searching. The useful question is the one almost nobody writing about this bothers to answer: will Domain let you build the thing you are actually trying to build?

The short answer

Yes. Domain has a real, public, self-serve API at developer.domain.com.au. You create an account with GitHub, Google or plain email, create a project, generate OAuth credentials, and read genuinely good documentation. Among the big property portals this is close to unique. Most of them have either no developer program at all or a partner form that goes to a sales team and never comes back.

The catch is not access. The catch is the licence attached to it. Domain's API terms grant you a "non-exclusive, non-transferable, non-sub-licensable, limited licence" to use the data "solely in accordance with the Approved Purpose", and the Approved Purpose is a line item in your contract, not a general permission to build. Everything below is about what fits inside that line and what does not.

Who owns Domain now, and why it matters

Worth knowing before you read the terms: Domain is no longer an independent Australian listed company. CoStar Group completed its purchase of Domain on 27 August 2025, having agreed in May 2025 to acquire 100% of the company for around A$3 billion. CoStar also owns Apartments.com, Homes.com and LoopNet, and it is the most litigious company in this industry when it comes to listing content. We went through that record in detail in why Apartments.com has no listings API. If the Domain terms below feel unusually tight, the ownership is part of the explanation.

What the official Domain API actually gives you

Credit where it is due, because this is a better developer product than most portals ship. The current catalogue lists thirteen packages, including Agents & Listings, Properties & Locations, Price Estimation, Rental AVM, Schools Data, Address Suggestions, Listings Management and Webhooks. Auth is OAuth 2.0 with client credentials, authorization code and implicit flows. Production lives at https://api.domain.com.au/.

The parts that most portals never publish at all:

• Rate limits, in numbers. Token generation is capped at 3000 Requests Per Hour, and a limit of 1000-3000 Requests Per Minute (depending on plan) applies to all API requests. Domain's rate limiting page notes this applies "regardless of your actual quota limit. This includes Unlimited plans."
• Quota headers on every response. X-Quota-PerMinute-Limit, X-Quota-PerMinute-Remaining, X-Quota-PerDay-Limit, X-Quota-PerDay-Remaining. Exceed one and you get a 429 with Retry-After and X-Quota-Exceeded telling you which ceiling you hit. Daily quotas reset at 10am AEST.
• A published SLA. 99% uptime over a rolling one month period and a 95th percentile response time within 900ms, with a 30-minute target response on severity 1 incidents.
• Sane pagination. pageNumber starts at 1, 20 items per page by default, 100 maximum, and an X-Total-Count response header when a reliable count exists.

That is a real API team's work, not a checkbox. If your use case fits the licence, use it. Seriously.

The four clauses that decide whether you can use it

This is the part the scraper-marketplace pages and the "top 10 property APIs" listicles skip entirely, and it is the whole ball game. Domain's API Terms and Conditions are public. Read clause 7.6 before you write a line of code.

7.6(g) prohibits derivative works. Not "prohibits reselling", not "prohibits redistributing". You may not "copy, modify, translate or create any Derivative Work of all or any portion of the API Product(s), the API Data or Our Content." And Derivative Work is defined at the top of the document as "a work or product that uses and/or is derived from the API Data and APIs." Read literally, that is most products a developer would want to build on listing data. In practice this is what the Approved Purpose is for: Domain tells you in writing which use case is permitted, and everything outside it is a breach.

9.1(d) then takes the upside. "Where we provide our prior written consent to the creation of a Derivative Work, you agree that all Intellectual Property Rights subsisting in the Derivative Work will vest in us." So the sanctioned path to building something derived from Domain data ends with Domain owning it. That is a sentence worth showing your co-founder before you architect around this API.

7.6(j) keeps the data onshore. You must not "access, use, and/or store the API Product(s) or otherwise make available the API Data outside of Australia." If your app runs on us-east-1, or your analytics warehouse sits in the US, or your team debugs production data from London, you are offside. This one quietly disqualifies a lot of otherwise reasonable architectures, and it is not a clause you can engineer around with a CDN.

7.6(d) closes the third-party door. No licensing, selling, renting, leasing, transferring, assigning, distributing, displaying, disclosing or otherwise commercially exploiting the data or making it available to any third party. Combined with 3.1's non-sub-licensable licence, you cannot pass Domain data through to your own customers as data. You can show it in your product, subject to the go-live rules below.

Two more that surprise people. Clause 5.8 requires you to "operate (and keep up to date) anti-scraping software" on your own application, so Domain's anti-bot problem becomes a line item in your roadmap. And clause 13.1 caps liability at the lesser of AUD$5,000 or twelve months of fees for paid products, and AUD$500 for free ones. Clause 13.2 then removes that cap for your breach of 7.6, which makes the risk asymmetric in the direction you would expect.

Before you go live, Domain redesigns part of your product

Assume you clear the licence. There is still a product review. Domain's FAQ lists what you must do before launch, and every item is a UI decision someone else is now making for you:

• Clearly display the "powered by Domain logo" on your site
• Send "Stats" back to the Domain platform
• Give users a way to view the original listing, with a Google UTM tag on the link
• Make sure contacting the agent is not behind a paywall or login screen
• Make sure no price estimate data is behind a paywall

Read those last two together and the shape becomes clear. The two things a subscription property product would most naturally gate, agent contact and valuations, are exactly the two things Domain requires you to leave open. That is not an accident of drafting. It is a portal making sure your product feeds its funnel rather than replacing it.

There is also a sign-off gate on the way to production, and package access is not entirely self-serve: the docs for adding APIs to a project say to "agree on the API required with your account manager." The sandbox will not fill the gap either, because it is scoped to write-heavy integrations. Domain states plainly that it "is NOT for testing regular read-only style applications", and that sandbox data is refreshed every Sunday and is "not production quality in terms of completeness, or accuracy."

Here is a walkthrough of the portal itself, if you want to see the sign-up flow before committing an afternoon to it:

Where the official API stops, even when you qualify

Three ceilings worth knowing before you design around it.

Search returns the first 1,000 results, full stop. The residential search reference says "Search results are limited to the first 1000 results" and tells you to refine the query instead. At 100 per page that is ten pages, which is fine for a suburb and useless for a state. Full-market pulls need bucketing by price band or suburb, the same workaround every capped search API forces on you.

Results are not a flat list. Each item is either a PropertyListing or a Project, where a Project groups new-development apartments and hangs the individual listings off it as children. If you write a naive for item in results loop you will silently drop every new-build apartment in the query.

You are discouraged from keeping the data. Domain's own guidance is that "it's not a good idea to store Listing data because prices, inspections and even the metadata about a property can change regularly", and it puts a number on the churn: "we see around 4,000 listing updates across the group each day." That is a fair warning about staleness, and it also means your historical dataset is your problem, not theirs.

Your four options in 2026

Every route to Domain listing data trades money against engineering time against how exposed you are when something changes upstream.

Option	Pricing	Setup effort	Where it hurts
Official Domain API	Free and paid tiers exist; no public rate card. Plans are split "based on what industry you're in, or how many API calls you make each month"	Hours to sign up, weeks to clear review	Approved Purpose gating, no derivative works, data must stay in Australia, mandatory logo and backlinks, 12-month initial term on paid schedules
DIY scraper (headless browser plus proxies)	"Free", plus proxies and your time	Days to build, forever to maintain	Anti-bot walls, markup changes, IP bans. Every scraper is a maintenance contract you signed with yourself
Scraper marketplace actors (e.g. Apify)	Roughly $0.70 to $1.00 per 1,000 results depending on the actor	Hours	You still own schemas, dedup, scheduling and monitoring, and actors break when the site shifts underneath them
Hosted REST endpoints (RealtyAPI)	Free tier, then subscription plans or pay-as-you-go credits (see pricing)	Minutes	Covers what domain.com.au publishes publicly, so no off-market records, no owner data, no history you did not capture yourself

If you are weighing build-it-yourself seriously, we laid out the general trade-off in web scraping vs. using an API. Short version: scraping wins when the data has no API at any price and your volume is tiny. It loses the moment uptime matters.

Is scraping domain.com.au legal?

The quiet question. Scraping publicly visible pages is not automatically illegal in Australia, and there is no Australian equivalent of a general database right. But Domain's site terms prohibit it, copyright subsists in listing photographs and descriptions, and CoStar has demonstrated internationally that it will litigate over listing images. The honest read is the same one we reach in is website scraping legal?: the legal risk is real and ambiguous, while the engineering pain is certain. Most teams do not stop scraping because a lawyer called. They stop because of maintenance.

What RealtyAPI's Domain.com.au endpoints cover

RealtyAPI runs hosted Domain.com.au endpoints as part of its real estate data platform. You call a normal REST endpoint with an API key, and proxies, anti-bot handling and markup drift stop being your problem. There is no Approved Purpose to negotiate and no logo you are contractually required to display. Ten endpoints cover the surface:

Endpoint	What it returns
GET /search/bylocation	Listings for a suburb, postcode, region or area, with the full filter set below
GET /search/bycoordinates	Listings within a radius of a latitude/longitude point
GET /search/byurl	Runs a domain.com.au search-results URL and resolves its filters for you
GET /details/byid	Full detail for one listing: price, description, photos and floor plans, agency and agent contacts, nearby schools, inspection and auction info, land area, market insights
GET /details/byurl	The same detail, resolved from a listing URL or a bare numeric id
GET /autocomplete	Location typeahead over suburbs, postcodes, regions, areas, schools and projects
GET /agent/search	Agents or agencies active in a location, with sale/sold/rent stats and review ratings
GET /agent/details	One agent or agency profile: contacts, agency, social links, statistics, rating
GET /agent/listings	An agent's or agency's current and recently sold listings, each tagged with its saleType
GET /agent/reviews	Reviews and overall star rating, with each reviewer's comments and the property reviewed

Auth is a single x-realtyapi-key header and responses are JSON. Domain sits in the standard set rather than the premium one, so the free plan reaches it while you are still deciding whether the data fits your product.

The filters that make it feel like Domain

Generic international listing APIs treat Australia as one more country, which is how you end up unable to express "three-bed house in Carlton, and I mean the Melbourne one." These are the Australia-native parameters that matter:

• location resolves through Domain's own typeahead, so Bondi Beach, Bondi Beach NSW, 2026 and Bondi Beach NSW 2026 all work. Append the state to disambiguate duplicated suburb names, which Australia has a lot of.
• searchType takes For_Sale, For_Rent or Sold, so sold comparables come from the same endpoint as live stock.
• surroundingSuburbs defaults to excluding neighbours. Set it to true deliberately, because it changes result counts a lot.
• propertyType accepts House, Apartment, Townhouse, Land, Rural and Retirement, plus Domain's own House & Land and New Homes category shortcuts for new developments.
• landArea in square metres, with min: and max: syntax, which is how Australian buyers actually shop for a block.
• sortOrder includes Inspection alongside the usual price and recency options, which is the ordering a Saturday open-home planner needs.
• The agent endpoints carry review ratings and sale statistics, so "which agent should we list with in this suburb" is a query rather than a research project.

Quick start: a Sydney listing in three requests

Base URL: https://domain.realtyapi.io. Auth: your key in the x-realtyapi-key header. Grab a key from the docs first; it takes about a minute.

1. Turn typed text into a place

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

Use this to build a suburb picker, or to sanity-check that the string your user typed maps to the place you think it does. Skip it if you already know the suburb and state.

2. Search listings

curl "https://domain.realtyapi.io/search/bylocation?location=Bondi%20Beach%20NSW&searchType=For_Sale&bedrooms=min:3&priceRange=min:1500000,max:4000000&propertyType=House&sortOrder=Newest" \
  -H "x-realtyapi-key: YOUR_KEY"

Note the range syntax: bedrooms, bathrooms, carspaces, landArea and priceRange all take min:, max:, or both comma-separated. Results are paged with page and resultCount (up to 100), and the response carries a nextPage flag so you know when to stop.

3. Pull the full listing

curl "https://domain.realtyapi.io/details/byid?id=2020755515" \
  -H "x-realtyapi-key: YOUR_KEY"

The id comes straight from a search result. If all you have is a link someone pasted into Slack, /details/byurl takes the domain.com.au URL instead and saves you a parsing step.

A production-ish Python loop

Same flow with pagination and the error handling you actually want, because any API fronting live web data will have a bad minute eventually:

import requests

BASE = "https://domain.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 search(location, **filters):
    page = 1
    while True:
        data = get("/search/bylocation", location=location,
                   page=page, resultCount=100, **filters)
        listings = data.get("listings") or data.get("results") or []
        if not listings:
            break
        for listing in listings:
            yield listing
        if not data.get("nextPage"):
            break
        page += 1

seen = set()
for listing in search("Bondi Beach NSW", searchType="For_Sale",
                      bedrooms="min:3", propertyType="House"):
    listing_id = listing.get("id")
    if listing_id in seen:      # paged results can overlap when stock moves
        continue
    seen.add(listing_id)
    print(listing_id)

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

Three habits worth keeping from that snippet. Read the rows defensively, so the same loop works across /search/bylocation, /search/bycoordinates and /search/byurl instead of hard-coding one shape. Dedupe by id rather than trusting page boundaries, because listings shift position between requests as stock changes. And stop on an empty page as well as on nextPage, so a hiccup upstream ends the loop instead of spinning it.

From there it is your product. Diff daily snapshots into Postgres for a price-drop watcher, join /agent/listings and /agent/reviews into an agent-performance dashboard, or pipe sortOrder=Inspection into a weekend open-home planner. The point of an API over a scraper is that this loop is the whole integration. There is no proxy pool underneath it for you to babysit at 2am. Ask me how I know.

What you still can't get

The honesty section. These endpoints return what domain.com.au publishes: active listings, recently sold stock, agent profiles and reviews. They are not a time machine and not a land registry. Long-run price history is something you build by snapshotting on a schedule, and the pagination loop above plus a cron job and a database gets you further than you would think. Owner names, title records and off-market data live with the state land registries and the paid data houses, not on the portal.

Coverage also follows Domain itself, and Domain is Australia's second largest real-estate marketing business rather than its leader, competing directly with REA Group's realestate.com.au. Plenty of agents list on both, but a listing that only ever went up on realestate.com.au is not going to appear here. If your product claims national coverage, plan on both sources. That is the same conclusion we reached for the US and UK portals in whether Redfin has an API, what counts as a Realtor.com API, which Rightmove APIs actually exist and the StreetEasy question. One portal is a segment. Two or more is a market.

Key takeaways

• Domain genuinely has a public API, and it is a good one. Self-serve signup, thirteen packages, published rate limits, quota headers on every response, and a real SLA. If your use case fits the licence, use the official product.
• The gate is the Approved Purpose, not the signup form. Clause 7.6(g) prohibits derivative works and 9.1(d) vests the IP in any permitted derivative back in Domain. Check that your product survives those two sentences before you build on them.
• Clause 7.6(j) is an architecture decision. API Data cannot be accessed, used, stored or made available outside Australia. That rules out the default region on most cloud accounts.
• Going live means shipping Domain's requirements too. Powered-by logo, stats callback, UTM-tagged backlink, and no paywall on agent contact or price estimates. The two things you would most want to gate are the two you cannot.
• Hosted endpoints trade the contract for a header. Ten endpoints, one x-realtyapi-key, Australian-native filters like surroundingSuburbs and landArea, and no product review before you launch.

If you are building for the Australian market, the quickest way to know whether this data fits is to run the three requests above against your own suburb and read what comes back. The free tier covers that comfortably, and it takes about ten minutes to find out.