Keys and tokens

doubleshift uses four kinds of secrets, and none of them stands in for another: a management token never authenticates a fragment call, nor a delivery API key a management call.

​

Which secret goes where

The two logs tokens are not interchangeable. A logs token only sends delivery records; if one is exposed, ask doubleshift to replace it.

​

Create a key

In the console, open Settings → API keys, give the key a name, then Create key. Only an owner of the account can create or revoke keys. The full key is shown once: copy it immediately. Afterwards the console lists only its prefix, never the secret. Keys are account-scoped: no per-site or per-fragment scope, and no expiry. A key stays valid until you revoke it.

​

Use it on every request

Send the key in the X-API-Key header of each fragment call. It keeps the key out of URLs, access logs and downstream caches. On GET /v1/fragment the header is the only place read: a key in the query string is ignored, so without the header the call answers 401 once it reaches authentication. A call refused earlier, such as one missing a parameter, answers before the key is read. On ESI, your CDN adds the header to the include subrequest (ESI), never the tag’s src. doubleshift checks the key on every call and finds your account from it:

• No key in the header, or an unknown or revoked key: 401.
• A valid key whose account is not the partner_id of the call: 403.

​

Rotate or revoke

You can hold several keys. To rotate, create a new key, switch your edge to it, check that the old key’s Last used stops moving, then Revoke the old one. Last used is updated at most once a minute, by calls that reach one of your fragments. Revocation refuses the next call: fragment responses are never cached (no cache), so no copy outlives it. Revoke any key you suspect has been exposed. A revoked key can then be deleted from the list; an active key must be revoked first.