Sentry: the DSN is public, the auth token is secret

Sentry: the DSN is public, the auth token is secret

Two credentials, two jobs

• DSN: the ingest address, made of the public key, the org ingest host, and the project ID. It goes in Sentry.init() / sentry_sdk.init(). It is meant to be visible, including in frontend bundles. It can only send events to one project; it cannot read anything or upload anything.
• Auth token: the credential for sentry-cli, source map uploads, release management, and the API. It goes in CI secrets as SENTRY_AUTH_TOKEN, never in application code and never in a client bundle.

Pick the right token type

• Organization token: limited permissions, designed for CI and sentry-cli. Default choice for uploads. Visible only once at creation; org owners get a security email when one is created.
• Internal integration token: custom permissions, full API access on behalf of the org. Use when org tokens cannot do the job (e.g. programmatically creating projects).
• Personal token: bound to you. Stops working if you leave the org. Never use in CI; it is the most common cause of uploads breaking months later when someone offboards.

The failure shapes

• Uploads fail with 401: the token is wrong, expired, revoked, or lacks scope. Check sentry-cli info.
• Events rejected with no clear error: the DSN points at the wrong project or org. Sentry validates DSN and project before parsing anything.
• Auth token found in a shipped JS bundle: rotate it immediately. It was never meant to be there.

Hygiene

One token per use case (uploads token != API automation token), so a compromise lets you revoke surgically. Scope CLI commands with SENTRY_ORG and SENTRY_PROJECT rather than relying on whatever the CI machine last used.