Skip to main content

Has a signer accepted the major this deployment serves?

POST 

/v1/click/deployments/:id/signer-status

Answers current when the signer has ever accepted the major this deployment serves, and stale otherwise, so you re-prompt only the signers whose consent no longer covers what they are shown. It is a read sent as a POST: the signer reference travels in the body, so it never appears in a URL or a request log.

  • Which acceptances count. Acceptances recorded through any deployment of the same template in the same environment. An acceptance in another environment never counts, and neither does a decline.
  • Currency. A minor or patch never makes a signer stale, and neither does a later acceptance of another major: a signer who accepted 3.x and later 2.x is current while 3.x is served. A signer who never accepted the served major is stale, including after a rollback to a major they never accepted.
  • Grace window. A version this deployment served until less than 15 minutes ago still counts for a signer who accepted it at most 15 minutes before it stopped being served, or after: an acceptance that raced the change, in the same window in which an acceptance of it is still recorded. graceEndsAt says when that ends. A signer who accepted it earlier is stale as soon as it stops being served, whatever the re-acceptance gate.
  • A signer who never accepted the template in this environment is stale with reason: never_accepted and accepted: null: prompt them to accept.
  • When stale, change carries the reason, the summary and the re-acceptance gate and deadline of the change that opened the served major, and change.sinceAccepted says what changed between the version the signer accepted and the served one, for the screen that asks them to accept again.

Request​

Responses​

The signer’s status against what the deployment serves

Response Headers
    X-Request-Id

    Correlation id for this request, returned on every response (success and error). Quote it when contacting support to pinpoint the exact request, and use it to correlate your own logs. It is the same 128-bit id as the trace-id segment of the traceparent header.

    traceparent

    W3C Trace Context identifier for this request, returned on every response. Send your own traceparent on a request to have it adopted, so a multi-call workflow shares one trace. Format: 00-<32-hex trace-id>-<16-hex span-id>-<2-hex flags>.