Consent Management v2 APIs
Consent Management v2 exposes three API groups:
| API group | Base path | Audience | Purpose |
|---|---|---|---|
| Configuration API | /consent-management/api/v1/config/ |
Administrators, console UI | For managing consent documents |
| Runtime API | /consent-management/api/v1/users/{userId}/ |
Integration developers, application backends | For integrating consent checks into your login and sign-up flows |
| Ledger API | /consent-management/api/v1/ledgers/ |
Compliance teams, auditors | For querying the consent audit trail |
Document data model
The document data model is retrieved in successful Configuration API responses.
Consent Management v2 organizes consent data in a three-level hierarchy:
DocumentDefinition
└── DocumentVersion (one or more)
└── DocumentLocalization (one per language)
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.
All API paths are relative to /consent-management.
Consent ledger
Every consent action is recorded as a new immutable entry in the consent ledger (consent_ledger_history), 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
- The exact document definition, version, and localization that was consented to
- The consent status (
GRANTED) - The timestamp
- The document title, URL, and lineage at the time of consent (denormalized 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.
