Obtain API credentials in the Didomi Console; generate a consent token via POST https://api.didomi.io/v1/consents/tokens with your API key in the Authorization header; the response returns a JWT consent_token.
When a user makes a consent choice in your UI, POST a consent event to https://api.didomi.io/v1/consents/events with body fields including user_id (your internal identifier), organization_id, organization_user_id, consents_purposes (array of {id, enabled}), and consents_vendors (array of {id, enabled, enabled_li}).
Retrieve current consent for a user via GET https://api.didomi.io/v1/consents/users/{user_id}; the response shows the current consent object with per-purpose and per-vendor status.
Fetch a proof of consent for audit purposes via GET https://api.didomi.io/v1/consents/proofs?user_id={user_id}; proofs include timestamps, the notice version shown, and the consent choices made.
For browser-side TCF consent string generation, listen to the Didomi SDK event didomi:ready and call Didomi.getUserConsentStatusForVendor(vendorId) or Didomi.getRequiredConsent() to read the __tcfapi-compatible output.
Paginate through consent events using the cursor returned in the response envelope when auditing large volumes of historical events.
Known gotchas
Consent tokens (JWTs) are scoped to a specific organization; using a token from one organization to write events for another will be rejected with 403.
Didomi events are append-only; there is no PATCH or DELETE — to update consent, POST a new event with the revised choices. The most recent event wins.
The proofs endpoint returns evidence tied to the UI widget version; if you built a fully custom UI without the Didomi SDK, proofs will not be generated automatically and you must manually attach your UI snapshot to the event record.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp