Skip to main content

Acceptances per template version

GET 
/v1/click/reports/acceptances

One row per template and version in one environment: how many acceptances were accepted, declined and expired in the window, how many distinct signers accepted, how many of those are current, and how many accepted acceptances were erased. Read it to see how far a re-acceptance campaign has got.

  • Window. from and to are required, inclusive, and at most 366 days apart. An acceptance falls in the window by when it was completed (or started, for one never completed).
  • Signers are distinct, non-erased signer references with an accepted acceptance of that version. A declined or expired acceptance never makes a signer.
  • Current uses the same rule as signer status, grace window included: a signer is current when they ever accepted a major that a deployment of the template in this environment serves. currentSigners counts the signers of the row who are current on at least one such deployment. A version of an older major can therefore have current signers, if they also accepted the major now served.
  • Erased acceptances (erasedAcceptances) are accepted acceptances whose signer identity was erased. They are counted only there: never in signers or currentSigners, and never merged into one signer.
  • servedBy lists the deployments whose served majors include this version’s major; graceEndsAt is set when only a superseded revision still serves it.
  • Filtering by signer is not possible here: a signer reference in a URL reaches load-balancer logs, so signerRef on this operation is a 400. Use POST /v1/click/reports/acceptances/query.
  • Caching. Every response, errors included, is Cache-Control: private, no-store.

Request​

Responses​

A page of report rows, newest version first within each template

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>.