Get consent status for end user
Returns an array of clickwrap template statuses for a specific end user, showing whether they have accepted, declined, or have pending actions for each template.
Use this to gate flows, build compliance dashboards, or audit consent without triggering the clickwrap dialog.
Authenticated — requires X-APP-ID and X-APP-KEY headers.
Status is returned only for the latest major version. Actions on
older major versions result in NO_DATA with a null timestamp.
Authorizations
Your application's App ID, sent as the X-APP-ID header.
Must be accompanied by X-APP-KEY for authenticated endpoints.
Your application's secret App Key (server-side only)
Path Parameters
The end user identifier
Response
Consent status retrieved
Unique identifier of the clickwrap template
Display name of the clickwrap template
Identifier of the related clickwrap event.
Present when the status is UNVERIFIED, PENDING, ACCEPTED, or DECLINED.
When the status is ACCEPTED, this value can be used directly with the certificate and agreement download endpoints.
Null when the status is NO_DATA or OVERDUE.
Major version of the template associated with this status
Minor version of the template associated with this status
Current interaction status of the end user:
NO_DATA— No recorded interactionPENDING— Clickwrap presented but user hasn't actedUNVERIFIED— User acted but event not yet verifiedACCEPTED— Event verified, user acceptedDECLINED— Event verified, user declinedOVERDUE— The mustAcceptBy deadline passed with no interaction
Most recent status change (UTC, ISO-8601), or null if no interaction recorded
Custom tags associated with the template
When the referenced template version became effective (UTC, ISO-8601)
Optional acceptance deadline configured in the ClickTerm UI, or null
true when the SDK should re-display the clickwrap even though the user
already has a binding acceptance on file. Unified across causes - it is
true when either:
- an unfulfilled re-acceptance request exists for this end user + template
(created via the
POST /clickwraps/re-acceptendpoint), or - the template has Always require re-acceptance enabled and the user has a prior accepted event for the current major version.
While re-acceptance is pending the status stays ACCEPTED - the prior
agreement remains binding, so there is no compliance gap. For a
request-based re-acceptance the flag clears once the user re-signs and the
new event is verified; for the always require re-acceptance setting it
stays true until the setting is turned off.

