Developer Hub


You’ll find our Github repository for the schemas at and more detailed developer info on

From time to time, we may need to make enhancements to our privacy practices. This may happen as the result of government regulation, recent technologies, or other developments in the area of privacy protection. Any updates to our privacy policy will be clearly posted on the website. 

Please contact us if you have any questions about our privacy policy or information we hold about you. 

You can contact us by email on or via the contact us link on the website. 

API Design

The API is specified using the OpenAPI Standard and in accordance with REST-ful principles. Mutability of the property data, or of historical claims, is not permitted; claims can only be added and the resulting property data state queried.

Claim Schema

OpenID Connect is primarily intended for claims about identity. As such, the data model within the claims object itself does not support the metadata necessary to identify the schema, path and attribution aspect of exchanging property data.

A PTDF-claim JSON Schema is supplied, against which claims embedded in the OpenID Connect verified claims object should be valid.

Supported Endpoints

In accordance with the restrictions on mutability of claims, the following endpoints are represented in the API Specification:

  • (POST) Add Claim – supplying a verified claims object (comprising either a single verified claim or an array of them) which is added to the list of claims for a given UPRN.
  • (GET) Claims – returning an array of verified claims for a given UPRN in chronological order of submission.
  • (GET) Current State – returning the JSON representation of the current state of the property data for a given UPRN. This output is likely to be all that most participants will require if they don’t need to represent the provenance of the data to their users.
  • (GET) Provenance Map – returning a JSON representation of the structure of the current state for a given UPRN but with Claims replacing the data. This output makes it straightforward to access provenance alongside the data when it’s displayed.
  • (POST) Subscribe – supplying a Callback URL to which newly submitted claims for a given UPRN should be POSTED. Servers should ensure timely event updates and make limited attempts at retries if the callback URL does not respond.
  • (DELETE) Subscribe – cancel the claim callback subscription for the given UPRN for this account

The PDTF API is versioned using Semantic Versioning. It is intended that future changes be made through extension of the existing specification, to retain backward compatibility with earlier versions. Over time, legacy versions may become deprecated but capabilities will only be removed when participants have had plenty of time to migrate their implementations.