Data Users

Create an Access Record

Registers a new access record on behalf of a Controller. Returns 201 and an access-token containing the new access key (ak), plus a Location header pointing to the created resource.

All records use the same AccessRecord schema. The processing.legal-basis value determines which additional fields are expected:

Consent bases — populate notice and access-event.consent.
Legitimate interests — populate lia-reference on the lead controller entry; set notice and access-event.consent to null.
Public task / legal obligation — populate statutory-reference on the lead controller entry; set notice and access-event.consent to null.
Contract — set notice and access-event.consent to null.

Historic records may be submitted — access-event.registered-at may predate record-metadata.created-at.

If the DCC has previously submitted a DISCOVERED record for the same MPxN and organisation, the register will link the two records on creation. The DISCOVERED record is retained for audit; the new full record becomes ACTIVE.

To update an existing record use PUT /access-records/{ak}.

Cross-DUID re-identification: To create an Access Record linked to an Identity Record originally created by another Data User, include a reidentification-token field in the request body (alongside the standard AccessRecord fields, without record-metadata.identity-record-ref). Obtain the token via POST /identity-records/reidentify. The register validates the token and resolves the ir internally.

POST

access-records

curl --request POST \
  --url https://api.central.consent/v1/access-records \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "record-metadata": {
    "schema-version": "1.0",
    "controller-arrangement": {
      "arrangement-type": "sole",
      "controllers": [
        {
          "name": "Bright Energy Ltd",
          "role": "sole",
          "contact-url": "https://bright-energy.com/contact",
          "address": {
            "addressLine1": "10 Canary Wharf",
            "townCity": "London",
            "postcode": "E14 5AB"
          },
          "privacy-rights-url": "https://bright-energy.com/your-rights"
        }
      ]
    },
    "identity-record-ref": "ir_a3c5e7f9b1d3a3c5e7f9b1d3"
  },
  "notice": {
    "shared-notice": {
      "terms-url": "https://bright-energy.com/privacy-v3.html",
      "notice-version": "v3.2",
      "notice-language": "en"
    }
  },
  "processing": {
    "legal-basis": "uk-consent",
    "purpose": "Energy efficiency analysis and tariff recommendations",
    "data-types": [
      "HH-CONSUMPTION",
      "HH-EXPORT"
    ]
  },
  "access-event": {
    "state": "ACTIVE",
    "registered-at": "2023-11-07T05:31:56Z",
    "expiry": "2027-11-10T17:07:01.580Z",
    "controller-reference": "REF-00123",
    "consent": {
      "consent-type": "expressed-consent",
      "method": "Explicit web checkbox"
    }
  }
}
'

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "access-token": {
    "key": "ak_691df0c788ca043403b7fa90",
    "expiry": "2023-11-07T05:31:56Z"
  }
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

Authorizations

Authorization

string

header

required

JWT from GET /auth/token. Pass as Authorization: Bearer <token>. Expires after 7200s.

Body

application/json

An AccessRecord. All legal bases use this same schema.

A data access record covering all lawful bases. The same schema is used regardless of processing.legal-basis. The notice field and access-event.consent sub-object are null for non-consent records and populated for consent records.

record-metadata

object

required

ISO 27560 Section 1 — Record Metadata

record-identifier and created-at are assigned by the register on creation and returned in responses; they must not be supplied in request bodies.

identity-record-ref links this access record to the Identity Record that holds the person-property relationship (PII principal, move-in date, address, and identity verification evidence). Supply the ir key returned when the Identity Record was created. The linked Identity Record must have been registered by the same authenticated Data User.

identity-record-ref is required when registering a new Access Record in the standard flow. It may be omitted when a reidentification-token is supplied in the POST /access-records request body — the register resolves the ir internally from the validated token.

Show child attributes

notice

object | null

required

Populated for consent-based records; null for all other legal bases.

Show child attributes

processing

object

required

ISO 27560 Section 3 — Processing Fields

Defines the shared scope and legal basis of data access. These fields apply to the access registration as a whole regardless of how many controllers are involved.

Per-controller compliance fields — privacy-rights-url, lia-reference, statutory-reference, and storage-conditions — are held on each Controller entry within record-metadata.controller-arrangement, where each controller bears individual accountability.

legal-basis applies to all controllers in the arrangement. For joint arrangements, all controllers must share the same legal basis — if purposes or bases differ, separate Access Records are required.

Show child attributes

access-event

object

required

ISO 27560 Section 4 — Access Event Fields

Records when access was registered, its lifecycle state and duration, and (for consent records) the specific details of how consent was expressed.

registered-at serves as the canonical event timestamp for all record types — for consent records it is the date the customer gave consent; for non-consent records it is the date the Controller registered their access.

revoked-at is set by the register on revocation and must not be supplied in request bodies.

consent is required when legal-basis is uk-consent or uk-explicit-consent. It must be omitted or null for all other legal bases (uk-public-task, uk-legitimate-interests, uk-legal-obligation, uk-contract).

Show child attributes

reidentification-token

string | null

Cross-DUID only. A confirmed token-ref obtained via POST /identity-records/reidentify. When supplied, identity-record-ref in record-metadata must be omitted — the register resolves the ir internally. The token is single-use, scoped to the initiating Data User, and expires one hour after issuance.

Response

Access record created successfully.

response

object

required

Show child attributes

access-token

object

required

The access token issued on successful registration. Pass to Data Providers to enable access verification.

Show child attributes

Last modified on March 25, 2026

curl --request POST \
  --url https://api.central.consent/v1/access-records \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "record-metadata": {
    "schema-version": "1.0",
    "controller-arrangement": {
      "arrangement-type": "sole",
      "controllers": [
        {
          "name": "Bright Energy Ltd",
          "role": "sole",
          "contact-url": "https://bright-energy.com/contact",
          "address": {
            "addressLine1": "10 Canary Wharf",
            "townCity": "London",
            "postcode": "E14 5AB"
          },
          "privacy-rights-url": "https://bright-energy.com/your-rights"
        }
      ]
    },
    "identity-record-ref": "ir_a3c5e7f9b1d3a3c5e7f9b1d3"
  },
  "notice": {
    "shared-notice": {
      "terms-url": "https://bright-energy.com/privacy-v3.html",
      "notice-version": "v3.2",
      "notice-language": "en"
    }
  },
  "processing": {
    "legal-basis": "uk-consent",
    "purpose": "Energy efficiency analysis and tariff recommendations",
    "data-types": [
      "HH-CONSUMPTION",
      "HH-EXPORT"
    ]
  },
  "access-event": {
    "state": "ACTIVE",
    "registered-at": "2023-11-07T05:31:56Z",
    "expiry": "2027-11-10T17:07:01.580Z",
    "controller-reference": "REF-00123",
    "consent": {
      "consent-type": "expressed-consent",
      "method": "Explicit web checkbox"
    }
  }
}
'

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "access-token": {
    "key": "ak_691df0c788ca043403b7fa90",
    "expiry": "2023-11-07T05:31:56Z"
  }
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

{
  "response": {
    "resource": "/v1/access-records/ak_691df0c788ca043403b7fa90",
    "timestamp": "2026-03-11T12:00:00Z",
    "transaction-id": "tid_691df0c788ca043403b7fa90"
  },
  "errors": [
    {
      "error-code": "VAL001",
      "message": "Field 'mpxn' does not match the required pattern."
    }
  ]
}

Documents

Identity Records

Re-identification

Authentication

Data Users

Data Providers

DCC

Webhooks

Create an Access Record

Authorizations

Body

Response