Consent Management v2 APIs

Consent Management v2 exposes three API groups:

Document consent data model

The document consent data model is retrieved in successful Configuration API responses.

Consent Management v2 organizes document consent data in a three-level hierarchy:

DocumentDefinition
└── DocumentVersion  (one or more)
    └── DocumentLocalization  (one per language)

Attribute consent data model

The attribute consent data model is also retrieved in successful Configuration API responses.

Attribute consent is organized in an equivalent three-level hierarchy:

PurposeDefinition
└── PurposeVersion  (one or more)
    └── PurposeLocalization  (one per language)

Each purpose version also carries two optional configuration objects:

• Data scope — the identity attributes linked to the processing purpose (for example, personal.email, personal.firstName).
• Preferences — the communication channels and contact frequencies permitted for the purpose (for example, EMAIL at MONTHLY frequency).

Runtime API

Your application backend calls the Runtime API during login using an OAuth2 Service-to-Service (S2S) or Machine-to-Machine (M2M) token. The Runtime API must never be called directly from a browser or mobile app, because it requires a client secret that must remain private.

For high-throughput login flows, the Runtime API uses a two-level caching strategy (in-memory and Redis) to evaluate outstanding consents in under five milliseconds for most requests.

The Runtime API covers two consent types:

• Document consent — check outstanding documents, register document consents in a batch.
• Attribute consent — retrieve the user's purpose consent posture, register or revoke attribute consents in a batch.

All API paths are relative to /consent-management.

Consent ledger

Every consent action — both document and attribute — is recorded as a new immutable entry in the consent ledger, which you can query with the Ledger API. The ledger is never modified or deleted. It is the authoritative source of truth for compliance reporting.

Each ledger entry captures:

• The user ID and the type of consent (DOCUMENT or ATTRIBUTE)
• The exact definition, version, and localization that was consented to (or revoked)
• The consent status (GRANTED or REVOKED)
• The timestamp and the actor who recorded the consent
• A denormalized snapshot of the definition name, version name, and localization content at the time of consent, preserved for audit resilience

Multi-tenancy

Consent Management v2 supports multiple tenants, each with complete data isolation at the schema level. Documents, versions, localizations, and consent records for one tenant are never visible to another tenant.

Tenant lifecycle events (tenant created, updated, deleted) are consumed from the OneWelcome Identity Platform event messaging bus and automatically provisioned or deprovisioned in the consent service.