SigSentry Documentation

Pick the right key type, mint it from the right dashboard page, and store the value before it disappears

API keys are created from the dashboard. There are three creation flows, one per key type. The page you start from decides what kind of key you mint — there's no scope picker on the form.

The full key value is shown once at creation time — there's no way to retrieve it again, so have a secret manager open before you click the button.

The three flows

Page	Mints	Permissions	Scope
Project → SDK Keys → New	`ss_pub_*`	Locked to `analysis:create` + `analysis:read`	Always one project
Project → API Keys → New	`ss_secret_*`	You pick from the full list	Always one project
Organization → API Keys → New	`ss_org_*`	You pick from the full list	Tenant-wide (any project)

For background on which type to pick, see picking a key type.

Fields

Name

Your label for the key — e.g. 'production-ingest', 'CI smoke tests', 'staging webhook receiver'. Pick something specific. Generic names like 'API Key 1' make leaks harder to triage.

Permissions

Multi-select from the available permissions on the secret/org flows. On the SDK Keys flow the permission set is locked and shown read-only.

The key type is implied by the page — there's no field for it.

Step-by-step

Open the right page

SDK key → Project → SDK Keys
Project API key → Project → API Keys
Org API key → Organization → API Keys

Click New key.

Pick a descriptive name. On the secret/org flows, select the permissions the integration needs. For CI and similar limited-use jobs, grant only analysis:create and analysis:read — see Permissions. On the SDK Keys flow, permissions are locked.

Copy the full key value

The success modal shows the entire key — ss_pub_…, ss_secret_…, or ss_org_… followed by a long random string. This is the only time the full value is visible.

Store it in a secret manager

Paste it directly into your secret manager (AWS Secrets Manager, GCP Secret Manager, Vault, 1Password, GitHub Actions secrets — whatever your team uses). Don't email, paste in chat, or commit to git.

Once dismissed, only the prefix is visible in the dashboard. If you didn't capture the full value, revoke the key and create a new one.

Sending the key

Include the key as a bearer token on the Authorization header:

curl -H "Authorization: Bearer ss_secret_abc123..." \
  https://api.sigsentry.com/v1/analyses

ss_secret_* and ss_pub_* keys carry their project binding implicitly — the API resolves the project from the key. For ss_org_* keys, also send the project ID:

curl -H "Authorization: Bearer ss_org_abc123..." \
     -H "X-Project-Id: <project-uuid>" \
  https://api.sigsentry.com/v1/analyses

Best practices

Never ship ss_secret_* or ss_org_* in client-side code. The SigSentry SDK throws at construction time if you pass either — you'll know immediately rather than discovering at runtime that a secret key shipped to a browser. Use ss_pub_* for client-side contexts.

Never commit a key to git, even briefly. Once a key hits a public or shared repo, treat it as compromised — revoke it and create a new one, even if you delete the commit. History persists.
Use environment variables. Read the key from process.env.SIGSENTRY_API_KEY (or your language's equivalent) so it's never in source.
Use a secret manager in production. Env vars are fine for local development; production deployments should pull from a managed secret store.
One key per integration. A key per service makes it easy to revoke a single integration without breaking the others, and makes the Last Used column actually useful.

Last-used tracking

Every key tracks a Last Used timestamp, visible in the dashboard's API Keys table. It updates each time the key is seen on a request. Use this column to:

Confirm a new key is actually being used after deploy
Spot dormant keys that can be safely revoked
Investigate a suspected leak by checking activity vs expectations

The dashboard surfaces a warning on any active key whose Last Used is more than 90 days ago.

Creating keys