Australian Property Data API: Make Your First Request in 5 Minutes

If you need Australian property data in an app, CRM, calculator, or client report, the annoying part often comes before the first API call.

Maybe you are waiting on a data contract. Maybe you have a CSV export sitting in someone's inbox. Maybe the product idea is still small enough that you just want to prove the data is useful before it turns into a procurement project.

The PropRadar Data API is built for that first useful step: get a key, resolve an address, pull the record, and see whether the data belongs in your workflow. It's plain JSON over HTTPS, with a free tier you can test before you commit to anything bigger.

Here is the route we'd take from a blank terminal to a useful response.

What the API gives you

Think of the API as a practical data layer for property work, not a warehouse dump. The endpoints are there to answer the questions people tend to ask while doing the job:

• Is this property currently on the market?
• What is the asking range?
• What is PropRadar's estimated value?
• What is the estimated rent and gross yield?
• What similar nearby properties have sold recently?
• What are the median prices, growth rates, yields, vacancy rate, and market signals for this suburb?

The main endpoints are:

Coverage is strongest where there is a recent market signal: current listings, recent listings, and recent sales. A long-held address that has not been advertised or sold for years may return 404 not_found. Suburb statistics are broader and cover thousands of Australian suburbs.

Who it is for

Use it anywhere someone is already looking up property context and copying it into another system.

Mortgage brokers can add property context to a CRM before a client meeting: asking range, estimated value, rent, yield, last sale, and suburb fundamentals. See the mortgage broker API workflow.

Buyer's agents can automate comparable sales research for client packs instead of rebuilding the same comp table by hand every week. See the buyer's agent API workflow.

Proptech builders can spend less time on data plumbing and more time on the product itself: scoring, dashboards, alerts, lending workflows, investment calculators, or reporting. See the proptech founder API workflow.

Analysts and content teams can enrich calculators, suburb pages, lead magnets, and internal spreadsheets with consistent property and suburb data.

Step 1: get a free API key

Open /developers, choose Get a free API key, and create a key from the developer dashboard. Copy it somewhere you won't accidentally commit it.

Keys start with pr_live_ and are only shown once in the dashboard.

The free tier gives you 50 credits, which is enough to run through the docs and wire a small prototype. Paid tiers can be started from the dashboard when you need more volume:

A credit is the unit of metered usage. Most requests cost 1 credit; a few that do materially more work cost more, and every response tells you what it cost in the X-Credits-Cost header. The current cost of each endpoint is published in the API docs.

No annual contract, and no sales call just to start testing.

Step 2: confirm your key works

Base URL:

https://api.propradar.com.au/v1

Authentication uses the X-API-Key header.

curl https://api.propradar.com.au/v1/health \
  -H "X-API-Key: pr_live_your_key_here"

Example response:

{
  "status": "ok",
  "plan": "free",
  "quota": {
    "limit": 100,
    "used": 1,
    "remaining": 99,
    "unit": "credits"
  },
  "timestamp": "2026-05-17T01:23:45.000Z"
}

If this works, the boring parts are correct: your key is valid, the header is in the right place, and your network path can reach the API.

Step 3: search for a property

Most integrations start with an address and postcode from a form, CRM, loan file, or spreadsheet, not a PropRadar ID. Use /v1/properties/search to resolve the address.

curl "https://api.propradar.com.au/v1/properties/search?address=1/8+Bristol+Road&postcode=3044" \
  -H "X-API-Key: pr_live_your_key_here"

Example response:

{
  "property_id": "a1b2c3d4",
  "found": true,
  "on_market": true,
  "sold_record_available": true
}

Store the property_id. You will use it for the full property record and for comparables.

Step 4: fetch the property record

PROPERTY_ID="a1b2c3d4" # use the property_id returned by search

curl "https://api.propradar.com.au/v1/properties/${PROPERTY_ID}" \
  -H "X-API-Key: pr_live_your_key_here"

Example response:

{
  "property_id": "a1b2c3d4",
  "address": {
    "full": "1/8 Bristol Road, PASCOE VALE, VIC, 3044",
    "suburb": "PASCOE VALE",
    "state": "VIC",
    "postcode": 3044
  },
  "attributes": {
    "bedrooms": 2,
    "bathrooms": 1,
    "parking": 2,
    "property_type": "Apartment"
  },
  "listing": {
    "on_market": true,
    "asking_price_low": 640000,
    "asking_price_high": 720000,
    "days_on_market": 14
  },
  "valuation": {
    "estimated_value": 661500,
    "confidence": "high",
    "as_of": "2026-05-15"
  },
  "rental": {
    "estimated_weekly": 494,
    "estimated_yield_pct": 3.88
  },
  "last_sale": {
    "sold_price": 580000,
    "sold_date": "2018-06-12"
  },
  "currency": "AUD"
}

For many broker and buyer's agent workflows, this is enough to stop tab-hopping: price context, rent estimate, yield, last sale, and a valuation signal in one response.

Step 5: pull sold comparables

When someone needs to see the evidence behind a valuation, request nearby sold comparables.

curl "https://api.propradar.com.au/v1/comparables?property_id=${PROPERTY_ID}&radius_m=1000&months=12&property_type=Apartment&beds=2" \
  -H "X-API-Key: pr_live_your_key_here"

Results include sold price, sold date, distance, property attributes, and days on market where available.

Where comparables tend to fit:

• Client report comp tables
• Broker valuation notes
• Buyer's agent shortlists
• Price confidence checks
• Internal risk flags when a property is listed well above or below nearby sales

Step 6: fetch suburb statistics

If your workflow starts with a suburb instead of a property, call the suburb endpoint. It is useful for suburb pages, filters, calculators, and market commentary where a single address is too narrow.

curl "https://api.propradar.com.au/v1/suburbs/VIC/Pascoe%20Vale" \
  -H "X-API-Key: pr_live_your_key_here"

The response includes suburb signals such as:

• house and unit medians
• gross rental yields
• rent and price growth across multiple time windows
• days on market
• vacancy rate
• market heat
• demographic snapshots
• distance to CBD

You can also page through recent suburb sales:

curl "https://api.propradar.com.au/v1/suburbs/VIC/Pascoe%20Vale/sold?limit=25" \
  -H "X-API-Key: pr_live_your_key_here"

Or current listings:

curl "https://api.propradar.com.au/v1/suburbs/VIC/Pascoe%20Vale/listings?limit=25" \
  -H "X-API-Key: pr_live_your_key_here"

The response includes pagination.next_cursor. Use that for the next page, especially for scheduled imports.

Stable pagination for daily jobs

If you are paginating /sold or /listings for an overnight import, this is the bit worth caring about: use cursor, not offset.

Offset pagination looks convenient and then bites you. When new sold records land between page fetches, every new row shifts the windows by one. The row that used to sit at the page boundary can be missed.

Cursor pagination anchors each page to the last row of the previous page, so inserts don't shift the in-flight result set.

# Page 1 (no cursor needed)
curl "https://api.propradar.com.au/v1/suburbs/VIC/Pascoe%20Vale/sold?limit=50" \
  -H "X-API-Key: pr_live_your_key_here"

The response payload includes:

{
  "sold": [ ... 50 rows ... ],
  "pagination": {
    "limit": 50,
    "next_cursor": "eyJkIjoiMjAyNi0wNS0wOSIsImkiOiI1NTdmNGIxOSJ9",
    "next_offset": 50
  }
}

For page 2, pass next_cursor back as the cursor parameter:

curl "https://api.propradar.com.au/v1/suburbs/VIC/Pascoe%20Vale/sold?limit=50&cursor=eyJkIjoiMjAyNi0wNS0wOSIsImkiOiI1NTdmNGIxOSJ9" \
  -H "X-API-Key: pr_live_your_key_here"

Keep going until next_cursor is null. The cursor is opaque and URL safe; do not try to decode or mutate it.

Offset pagination still works for one-off browsing, but don't use it for production jobs.

Batch lookups with safe retries (Pro+)

On Pro and Scale plans, you can resolve up to 100 addresses in a single POST.

curl -X POST https://api.propradar.com.au/v1/properties/bulk \
  -H "X-API-Key: pr_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "addresses": [
      { "address": "1/8 Bristol Road", "postcode": "3044" },
      { "address": "284 O'\''Hea Street", "postcode": "3044" }
    ]
  }'

Each item comes back resolved, or with found:false if the address is not in our dataset. The batch costs 1 credit per address resolved, the same as looking each one up individually, so you keep the single round trip without paying less for the same rows. Malformed entries are not charged.

If your client retries after transient network failures, send an Idempotency-Key header. A replay with the same key and the same body returns the cached response and refunds the credits it cost:

curl -X POST https://api.propradar.com.au/v1/properties/bulk \
  -H "X-API-Key: pr_live_your_key_here" \
  -H "Idempotency-Key: c3a1b2d4-e5f6-7890-1234-567890abcdef" \
  -H "Content-Type: application/json" \
  -d '{ "addresses": [ ... ] }'

Replays carry the header Idempotent-Replayed: true so you can tell them apart from the original. Reusing the same key with a different body returns 422 idempotency_key_mismatch, so a buggy client can't accidentally overwrite a result.

Records expire after 24 hours.

Response rules to know

Everything is JSON over HTTPS.

Money values are in AUD. Dollar fields are returned as integer dollars to avoid floating point surprises.

Dates are ISO 8601.

Property IDs are stable 8-character IDs derived from the normalised address.

Credit and rate limit state is exposed in response headers, so your client can slow down before it hits the wall:

• X-Credits-Cost: what this request cost. Most are 1.
• X-RateLimit-Limit and X-RateLimit-Remaining: monthly credit allowance and what's left this period.
• X-RateLimit-Burst and X-RateLimit-Burst-Remaining: burst capacity and tokens left.
• X-API-Plan: the plan your key is on.
• Retry-After: only on 429s; seconds to back off before retrying.

Two distinct 429s can fire. quota_exceeded means your credits are gone for the period, or that the operation costs more credits than you have left (resets on the 1st of next month, Australia/Melbourne). rate_limited means you've drained the burst bucket; wait the Retry-After seconds and retry. The bucket refills continuously at your plan's steady rate.

Your client should watch X-RateLimit-Remaining and alert before running out, and respect Retry-After to avoid burst storms. Note that X-RateLimit-Remaining counts credits, so a loop over an endpoint costing 5 drains it five times faster than the request count suggests.

Error codes

Common responses:

A 404 on a property is not always a bug. It usually means the address is outside the currently indexed property coverage.

Integration tips

A few things we'd wire up before putting this in front of users:

Cache property and suburb responses where your use case allows it. Suburb statistics do not need to be fetched on every page load.

Store property_id after address search so you do not resolve the same address repeatedly.

Use /v1/health in deployment checks and scheduled monitors.

Keep API keys on your server. Do not expose pr_live_ keys in browser JavaScript.

Use cursor (not offset) for any pagination job that runs on a schedule. Offset can silently drop rows when new data inserts between page fetches.

For batch lookups that you'll retry on flaky networks, send an Idempotency-Key header so the second attempt doesn't burn credits twice.

Check your dashboard for endpoint usage. It shows which endpoints account for the bulk of your monthly calls, the error rate for each, and the median latency. That's the fastest way to spot a misbehaving client.

Use the OpenAPI spec if you want generated client types:

https://api.propradar.com.au/v1/openapi.json

Try it without writing code

The quickest way to inspect responses is the browser playground:

Open the API playground

Paste your key, choose an endpoint, and run a real request from the docs page. When you are ready to wire it into a product, the full reference is here:

Read the API docs

You can also check uptime and data freshness here:

View API status

Frequently asked questions

Is there a free Australian property data API?

Yes. PropRadar has a free developer tier for testing the Australian property data API. It is there for real integration work, not just static sample responses.

Do I need a credit card?

No. You can create a free key and make test calls without adding a card.

Does the API cover every property in Australia?

No. Property coverage is strongest for currently listed, recently listed, and recently sold properties. Suburb statistics cover a much broader set of Australian suburbs.

Can I use it in a product my clients see?

Yes, but keep your API key on your server and call PropRadar from your backend. Do not ship your live key to the browser.

What should I build first?

Start with a small workflow that saves time immediately: address lookup, property summary, sold comparables, or suburb statistics. Once that works, add caching, monitoring, and alerts on remaining credits.

Start here

If you only remember the path:

1. Create a free key at /developers.
2. Run /v1/health.
3. Resolve one address with /v1/properties/search.
4. Fetch that property with /v1/properties/{property_id}.
5. Add /v1/comparables or /v1/suburbs/{state}/{suburb} when your workflow needs more context.

That is enough to turn a manual property lookup into a repeatable API workflow.