Request clickwrap re-acceptance
Marks one or more end users’ prior clickwrap acceptances as stale so the SDK
re-displays the clickwrap on their next GET /clickwrap, prompting them to
sign again against the current template content and placeholder values.
Typically called from your backend’s profile-update handler when details that were filled into the agreement change (such as the user’s name, address, or company). ClickTerm does not detect these changes for you - you decide when a re-acceptance is needed.
The set of pairs evaluated is the cartesian product of endUserIds ×
clickwrapTemplateIds. Each pair is evaluated independently and produces
exactly one entry in results.
The user’s previous acceptance event remains valid and binding - it is never
invalidated, so there is no compliance gap. The consent status endpoint keeps
reporting status: ACCEPTED based on that event; the new reAcceptanceRequired
field is simply an extra signal that the clickwrap should be shown again so the
user can re-accept.
Authenticated - requires X-APP-ID and X-APP-KEY headers. All
resolution is scoped to the calling app.
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)
Body
Identifies which end users and templates to mark for re-acceptance
External end-user identifiers (your own IDs). Each is resolved under the calling app. Must be non-empty.
1Clickwrap template IDs to mark for re-acceptance. Each is resolved under the calling app. Must be non-empty.
1Optional free-text note stored for audit. Max 500 characters.
500
