chore: update v3 OpenAPI specs to v3.821.0

[Ed Fricker (beastawakens)]

User description

Automated v3 OpenAPI spec update for v3.821.0.

Triggered by Ed Fricker (@beastawakens) - assigned to you in case it needs a manual merge.

---

PR Type

Documentation, Enhancement

---

Description

• Add consent object to /v3/token payload schema

• Document consent binding in all v3 entry specs

• Add 400 error examples for partial consent

• Update CHANGELOG for v3.821.0 release

---

Diagram Walkthrough

flowchart LR
  token["/v3/token payload"] -- "new field" --> consent["consent object (ISO 27560)"]
  consent -- "injected server-side" --> entries["v3 entry endpoints"]
  token -- "new 400 example" --> errors["partialConsent error"]

Loading

File Walkthrough

	Relevant files
Documentation	6 files CHANGELOG.md Add v3.821.0 release entry                                                              +12/-0    v3-biometric-enrollment-entry.yaml Document consent fields in token payload description          +6/-6      v3-biometric-kyc-entry.yaml Document consent fields in token payload description          +7/-6      v3-document-verification-entry.yaml Document consent fields in token payload description          +7/-6      v3-enhanced-document-verification-entry.yaml Document consent fields in token payload description          +7/-6      v3-enhanced-kyc-entry.yaml Document consent fields in token payload description          +7/-6
Enhancement	2 files openapi.yaml Add token payload consent schema and 400 examples                +67/-13  v3-token.yaml Add consent object to token payload and error examples      +68/-11

---

---

Need help?

Type /help how to ... in the comments thread for any questions about PR-Agent usage.

Check out the documentation for more information.

[prfectionist]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🏅 Score: 85

🧪 No relevant tests

🔒 No security concerns identified

🔀 No multiple PR themes

⚡ Recommended focus areas for review Schema Duplication The consent schema is defined inline in the token payload (in both openapi.yaml and v3-token.yaml) while the description states it is "the same nested object the v3 entry endpoints accept". Since the entry endpoints define their own consent schema, there are now multiple independent copies that can drift (e.g. if an entry endpoint later accepts an extra consent field, the token payload's additionalProperties: false would reject it while the docs still claim identical shape). Extracting a shared component schema and $ref-ing it would prevent that. consent: type: object description: >- ISO 27560 consent record, in the same shape the v3 entry endpoints accept. Optional as a whole; when present, all four fields are required and no other field is allowed. Injected as `consent` on downstream endpoints, so a request that carries it need not repeat consent in the body. required: - granted - granted_at - notice_language - notice_privacy_policy_url additionalProperties: false properties: granted: type: boolean description: >- Whether the end user granted consent. Must be `true`; any other value is rejected. enum: - true example: true granted_at: type: string format: date-time description: >- When consent was granted, as an ISO 8601 timestamp. Must not be more than a minute in the future, so a value stamped from your own clock is fine. Include the timezone — without one the value is read as UTC. example: '2026-01-01T09:00:00.000Z' notice_language: type: string pattern: ^[A-Za-z]{2}$ description: >- Two-letter ISO 639-1 code for the language the privacy notice was shown in. Normalised to uppercase. example: EN notice_privacy_policy_url: type: string format: uri description: >- URL of the privacy notice the end user was shown. Must use the http or https scheme. example: https://example.com/privacy-policy Doc Inconsistency notice_language is documented as a two-letter ISO 639-1 code but the pattern accepts any case and the example uses uppercase EN, while ISO 639-1 codes are canonically lowercase. The note "Normalised to uppercase" further conflicts with the standard, which may confuse integrators and generated clients about what value to send/expect back. notice_language: type: string pattern: '^[A-Za-z]{2}$' description: >- Two-letter ISO 639-1 code for the language the privacy notice was shown in. Normalised to uppercase. example: EN

[prfectionist]

Suggestion: format: date-time implies RFC 3339, which mandates a timezone offset, so schema validators and generated clients will reject the timezone-less values the description explicitly allows. Align the schema with the documented behaviour (e.g. drop the strict format or state that the offset is required). [general, importance: 5]

Suggested change

	granted_at:
	type: string
	format: date-time
	description: >-
	When consent was granted, as an ISO 8601 timestamp.
	Must not be more than a minute in the future, so a
	value stamped from your own clock is fine. Include
	the timezone — without one the value is read as UTC.
	example: '2026-01-01T09:00:00.000Z'
	granted_at:
	type: string
	description: >-
	When consent was granted, as an ISO 8601 timestamp
	(RFC 3339 preferred). Must not be more than a minute
	in the future, so a value stamped from your own clock
	is fine. Include the timezone — without one the value
	is read as UTC.
	example: '2026-01-01T09:00:00.000Z'