Need help with your APIs? I offer API discovery, governance & evangelism services. Explore services →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC
NSW Land Registry Services website screenshot

NSW Land Registry Services

NSW Land Registry Services (NSW LRS) operates the Torrens Title Register for New South Wales, Australia's largest property market, under a concession granted by the NSW Government on 1 July 2017 and held by Australian Registry Investments Pty Ltd (ACN 617 926 020) as trustee for the Australian Registry Investments Trust. It is a privatised operator of a public record: the Registrar General retains the statutory authority and the Office of the Registrar General regulates the concession, while NSW LRS runs the register, examines and registers dealings and plans, and sells access to the resulting data. It sits at the legal foundation of the Australian value chain, beneath the REA Group and Domain portal duopoly, beneath PropTrack and CoreLogic valuation, and beneath PEXA and Sympli, the Electronic Lodgment Network Operators through which every Real Property Act dealing must now be lodged. Its API posture is the sharpest example in this study of a registry that is technically modern and commercially closed. There is no developer portal, no developer or docs subdomain, no published API programme, no OpenAPI or Swagger document, no SDK, no Postman workspace and no GitHub organization. One documented, anonymously callable API does exist, and it is not about land: the NSW LRS status page is an Atlassian Statuspage with the public v2 API enabled and referenced at status.nswlrs.com.au/api, publishing 27 components — among them an "API Service" component under Information Broker Services that confirms from the registry's own mouth that a production API estate sits behind the broker licence — plus RSS and Atom incident feeds and webhook notifications on incident and component changes. Access to the register itself is gated behind a licence: the site states plainly that "Only an information broker we've authorised can access our records", and those brokers — InfoTrack, Dye & Durham, Equifax, CITEC Confirm, TriSearch, Landchecker, Fynd, PSI Global and others — "deliver and on-sell land titling and related property information through an official licence agreement with NSW LRS". Wholesale data products (Property Alerts, Lease Notifications, Mortgage Insights, Mortgage Verifications) are sold by emailing [email protected], with no self-serve path and no published technical contract. What does exist, and what this profile records, are three genuinely reachable machine-readable surfaces that NSW LRS never advertises to developers: a Cantaloupe IIIF Image API 2.0 Level 2 endpoint serving the scanned historical land records behind the Historical Land Records Viewer, an anonymously callable Elasticsearch search proxy over 7,160,622 indexed historical documents, and a publicly downloadable W3C XML Schema for the ICSM ePlan Cadastral Information File enumerated types that pins the NSW LandXML jurisdictional vocabulary now mandatory for digital plan lodgment. The contracts are open; the licence is not — the HLRV terms of use prohibit on-supply, data aggregation, republishing and "any device, software or routine to abuse the service of HLRV or emulate human interaction and operation". RESO is entirely absent: NSW LRS appears nowhere in RESO's certified-organizations list, there is no RESO Web API or Data Dictionary certification, no OData $metadata document and no Universal Property Identifier, which is the expected answer for Australia, where RESO is a North American NAR construct with no adoption. No open, unlicensed dataset is published — NSW LRS is not a publishing organization on data.nsw.gov.au — and a privatised registry selling the public record back through a licensed broker channel is itself the finding. The registry does publish its language: a 257-term glossary of NSW land titling definitions, harvested here as the controlled vocabulary that stands in for the data dictionary it never wrote.

agent aware

Limited machine-readable signal and partial portal coverage — documentation a human can read, but little a machine or agent can consume without scraping.

Kin Score

API Evangelist profiles NSW Land Registry Services the way a machine reads it — 11 machine-readable artifacts across 3 APIs, pulled from the provider's own public surface and indexed so a developer, an analyst, or an AI agent can evaluate it against every other provider on the network.

Every provider in the network is reduced to the same set of machine-readable artifacts — OpenAPI contracts, event specifications, GraphQL schemas, runnable collections, pricing and rate-limit signals, security posture, OAuth scopes, and the agent surfaces (MCP servers and skills) that let software drive the API on its own. We profile them because the interface is the part of a company you can actually inspect: it is a truer signal of what a provider does than any marketing page. From those artifacts we compute the Kin Score — NSW Land Registry Services scores 40.7/100 (thin), with a separate agent-readiness read of 30/100 (agent aware). The full breakdown is below, followed by every artifact we hold — each card links through to its machine-readable definition on apis.io.

Kin Score

This is the API Evangelist rating — a single, repeatable read computed from the artifacts on this page. Green fill is points earned; the red track is points possible, so every bar shows earned-versus-possible at a glance.

Kin Score Kin Score How this is scored →
scored 2026-07-27 · rubric v0.5
Composite quality — 40.7/100 · thin
Contract Quality 5.7 / 25
Developer Ergonomics 7.0 / 20
Commercial Clarity 8.9 / 20
Operational Transparency 5.1 / 13
Governance 1.6 / 12
Discoverability 10.0 / 10
Regulatory · Government & Public Sector 8.1 / 15
Agent readiness — 30/100 · agent aware
Machine-Readable Contract 0 / 18
Agentic Access Contract 0 / 15
MCP Server 0 / 12
Machine-Readable Auth 10 / 10
Idempotency 0 / 9
Stable Error Semantics 8 / 8
Request/Response Examples 7 / 7
Rate-Limit Signaling 0 / 7
Typed Event Surface 6 / 6
Agent Skills 0 / 5
Well-Known Catalog 0 / 4
Consent & Bot Identity 0 / 3

How we profile NSW Land Registry Services

Each block below is one kind of artifact we hold for NSW Land Registry Services. For each we say what it is and why it earns a place in the profile, then list every one we've indexed — capped at two rows, scroll within the panel for the rest.

APIs 3

Each API is captured as its own OpenAPI definition — every operation, parameter, and response. This is the single most useful machine-readable description of what an API does, and it's what lets us score, lint, mock, and generate against it without asking the provider for anything.

Individual APIs this provider publishes, each with its own machine-readable definition.

NSW LRS Historical Land Records Viewer IIIF Image API

A live Cantaloupe Image Server exposing the International Image Interoperability Framework (IIIF) Image API 2.x over the scanned NSW land record images behind the Historical Lan...

NSW LRS Historical Land Records Viewer Document Search API

An Elasticsearch search proxy that backs the Historical Land Records Viewer and answers anonymously. Verified on 2026-07-26: POST https://api.lrsnative.com.au/hlrv/documents/_ms...

NSW LRS Status API

The one documented, publicly callable API NSW Land Registry Services operates. The NSW LRS status page at status.nswlrs.com.au is an Atlassian Statuspage (page id jcfp2nmyt2j4) ...

Event Specifications 1

Not every API is request/response. AsyncAPI describes the event-driven and streaming side — the webhooks and channels — so the asynchronous half of the interface is documented the same way the synchronous half is.

AsyncAPI definitions for this provider's event-driven and streaming APIs.

Examples 5

Real request and response payloads are what turn a spec from abstract into obvious — and they're one of the twelve things an agent needs to call an API correctly on the first try.

Example request and response payloads for these APIs.

Security Posture 2

Authentication, domain security, vulnerability disclosure, and trust-center signals — the evidence that a provider takes security seriously enough to document it. We profile it because you can't govern what you can't see.

Authentication, domain security, vulnerability disclosure, and trust-center signals.

Nsw Land Registry Authentication

none/contract-gated/session-login · 6 schemes

SECURITY

Nsw Land Registry Domain Security

TLSv1.3 · HSTS · DNSSEC

SECURITY

Resources

Every other property we hold for NSW Land Registry Services — documentation, portals, status pages, policies, and corporate surface — grouped by the job it does, following the integrator's arc from getting started to running in production.

Get Started 4

Portal, sign-up, and the first successful call

Agent Surfaces 1

MCP servers, agent skills, and machine-readable catalogs

Build 1

SDKs, sample code, and the tooling you integrate with

Access & Security 2

Authentication, authorization, and security posture

Commercial 3

Pricing, plans, and the legal terms of use

Company 3

The organization behind the API

Other 3

Properties that don't map to a standard resource type

← All providers · Data indexed from github.com/api-evangelist/nsw-land-registry · machine-readable index on apis.io