Docs

Keys

Cueston uses a different key for each job, so nothing secret ever ships in your page source.

KeyWhere it livesWhat it can do
pk_…Your site's page source (the snippet)Read published guidance and send analytics. Nothing else.
pk_test_…Your staging app's snippetThe same, for content published to staging.
sk_…Your server, scripts, CI, the CLI, the Chrome extensionActs as the person who created it, with their current role. Revocable.
tl_…Old snippets (embed.js data-token)Legacy: now read-only like pk_. Replace it, then revoke it in Settings → Install.

Publishable keys

pk_ keys are public by design. To stop other sites from using yours, add your domains to allowed domains. To stop someone from impersonating your users, turn on identity verification. If a key leaks somewhere unwanted, rotate it in Settings → Install.

Secret API keys

An sk_ key acts as the person who created it, with their current role: if their role changes, so does what the key can do, and once they leave the workspace their keys stop working.

  • Create keys in Settings → API keys. A key's secret is shown once.
  • Send it in the Authorization: Bearer sk_… header. Keys in a URL are refused, because URLs end up in logs.
  • Some account actions never accept a key, even an owner's: changing passwords, managing other keys, billing, single sign-on and SCIM settings, and rotating publishable keys.
  • People with "See and revoke every member's API keys" can revoke anyone's keys.

Other secrets

SecretPrefixWhere
Identity verification secretiv_Settings → Security. Signs user ids on your server.
Webhook signing secretwhsec_Each webhook endpoint. Verifies requests from Cueston.
SCIM tokenscim_Settings → Security. Your identity provider's provisioning.

Every secret can be rotated. Identity and webhook secrets keep the previous one working for 24 hours so you can deploy first.

On this page