DSN, ingest keys, ping URLs, tokens and node tickets
What each Belvador credential can do, whether it is secret, where you get it, how long it lasts and how to revoke it; none of them is an admin key.
On this page
Belvador uses a different credential for each job, so a leaked one can only do that job. None of them is an admin key for your whole workspace.
The credentials#
| Credential | Looks like | Secret? | What it can do | Where you get it |
|---|---|---|---|---|
| DSN | https://<public-key>@…/<project-id> | No — it ships in browser code | Send errors, check-ins and connection checks to one project. It cannot read anything | Project page (Projects and DSN) |
| Ingest key | bvi_… | Yes — server only | Send OpenTelemetry traces and logs (and check-ins, when the project requires a key) to one project, for the signals and environments you tick. It cannot read anything | Project settings → Ingest keys, shown once (quickstart) |
| Ping URL | a URL with a long random token | Yes | Report runs for one ping URL monitor. It cannot read anything | The monitor page (Ping URL monitors) |
| Upload token | a token for sentry-cli | Yes — keep it in CI secrets | Upload source maps for one project, 60 requests per hour, valid for 365 days | Project settings → Upload tokens, shown once (Source maps) |
| Node ticket | short signed text you never handle | — | Lets your browser read your node through Belvador's edge after the app checked your role: reading lasts at most 5 minutes, a change at most 60 seconds and works once | Issued by the app for each page you open |
| Personal API token | blv_pat_… | Yes — server or agent only | Call the REST API as you, inside one workspace, limited to the scopes, projects and environments you pick and never above your current role. Lasts at most 365 days | Account → API tokens, shown once |
| Service token | blv_svc_… | Yes — keep it in CI or server secrets | Call the REST API as a workspace service account (for CI and other systems), with the same limits; it keeps working when the person who made it leaves | Workspace settings → Service accounts, shown once |
| OAuth app access | blv_oat_… (access), blv_ort_… (refresh) — the app keeps them | Yes — held by the app you connected | Call the REST API as you from an app you approved on belvador.dev, with the workspace, permissions, projects and environments you picked and never above your role. Access lasts 60 minutes and renews; it stops after 30 days without use | The app asks; you approve on belvador.dev. See and disconnect under Account → Connected apps |
| Your session | your sign-in | — | Everything your workspace role allows; sensitive actions also ask for a fresh authenticator code | Sign in |
Rules that apply to all of them#
Shown once. Secret credentials are displayed only when they are created. Belvador keeps a hash, never the value, and shows a short prefix so you can tell them apart.
Revocable. Revoking takes effect within about a minute everywhere. Creating and revoking keys and tokens asks for your authenticator code and is written to the audit log.
Filtered from logs and alerts. Belvador's own logs and alert messages pass through a secret filter that removes Belvador key formats and other long tokens.
No read access from the sending side. A leaked DSN, ingest key or ping URL lets someone send data to your project, not read it. Revoke it and create a new one.
API tokens never act alone on sensitive things#
A token can read and make ordinary changes. Keys, members, alert destinations and node changes answer APPROVAL_REQUIRED: a person approves on belvador.dev with a fresh authenticator code. A token never carries that code.
AI agents#
An AI agent connects through the MCP server — with OAuth where its tool supports it, otherwise with a read-only personal token read from an environment variable — or calls the REST API directly. Either way it holds an ordinary token, so the rule above applies: it never approves sensitive changes. See also For AI agents.
Spotted something wrong or missing? Tell us: hello@belvador.dev