Consents (v2)

Biometry has two consent mechanisms, and they are not interchangeable:

	Where	What it gates
Platform consent	/api-consent/consent, /api-consent/strg-consent	Whether face/voice recognition may run, and whether biometric templates may be stored. Enrollment and verification enforce it. See Consent.
Custom consents	/v2/consents/*	Your own consent documents (terms, disclosures) that you want end-users to approve and that you need an auditable record of. Nothing in the pipeline enforces them — they are a record you can query.

This page covers custom consents. For the consent that gates biometric processing, use the platform consent endpoints — including on v2, passing your user_id as user_fullname.

Record an approval

POST https://api.biometrysolutions.com/api-gateway/v2/consents/{id}/approve/{user_id}

Authorization

Project API token as Bearer — this is the one custom-consent endpoint your backend calls.

Path parameters

• id* — the consent document ID.
• user_id* — the end-user approving it.

Example

curl --request POST 'https://api.biometrysolutions.com/api-gateway/v2/consents/6f2a1b3c/approve/8f14e45f' \
     --header 'Authorization: Bearer YOUR_API_TOKEN'

Responses

200

{ "meta": { "request_id": "2b3c…", "message": "consent approved" } }

403

The consent document belongs to another project.

{ "error": { "code": "forbidden", "message": "you have no access to this consent" },
  "meta": { "request_id": "2b3c…" } }

409

The user already approved this consent version — approvals are recorded once per version.

{ "error": { "code": "conflict", "message": "consent already approved" },
  "meta": { "request_id": "2b3c…" } }

The approval is always recorded against the latest version of the consent document.

List a user’s approvals

GET https://api.biometrysolutions.com/api-gateway/v2/consents/my-approvals/{user_id}

Authorization

Project API token as Bearer.

Example

curl 'https://api.biometrysolutions.com/api-gateway/v2/consents/my-approvals/8f14e45f' \
     --header 'Authorization: Bearer YOUR_API_TOKEN'

Responses

200

{
  "data": [
    { "consent_id": "6f2a1b3c", "user_id": "8f14e45f", "approved_at": "2026-07-14T09:12:31Z" }
  ],
  "meta": { "request_id": "3c4d…" }
}

Managing consent documents

Creating (POST /v2/consents), reading (GET /v2/consents/{id}) and updating (PATCH /v2/consents/{id}) a consent document require a Console user session — they are authoring operations, done from the dashboard. A consent document carries a header, a body and the journey_id it belongs to; updating it appends a new version rather than overwriting, so past approvals stay attributable to the text that was approved.

Your backend only ever needs the two API-token endpoints above.