Project token and private keys

When integrating your application with monitoring, two elements matter most: the project token and the private key. They serve different purposes and shouldn't be treated as interchangeable.

Project token

The token identifies the project that reported events should reach. It's used by the endpoint that accepts data and lets each event be assigned to the right application.

The token alone shouldn't be treated as the only authentication mechanism. Wherever an integration uses a private key, both elements should be stored according to security best practices.

Private key

The private key is used to authenticate the data being sent. Treat it as an application secret: don't place it in a repository, in front-end code, or anywhere accessible to visitors of the site.

A good approach is to store it in an environment variable or in the server configuration. This means changing the key doesn't require modifying the application's code.

A project can have multiple keys

If a project runs across several environments or servers, separate keys make access management easier. For example, you can use one key for production and a separate one for the test environment.

This also limits the impact of a potential leak. If a key used by one server needs to be revoked, you don't have to change the configuration of every other installation.

Where can you find the project data?

The information needed to configure integrations can be found in the project settings and the API keys section. Copy it directly from the panel instead of retyping it by hand.

How do you pass the key to the API?

Integrations can authenticate requests according to the supported API format. When using the REST API directly, the simplest approach is to pass the key as a Bearer header:

Authorization: Bearer PROJECT_PRIVATE_KEY

The project token is part of the endpoint address, while the private key goes in the authentication header.

Don't put the key in the browser

Any code that runs in the browser can be read by the user. The private key should therefore never end up in JavaScript, HTML, or a public endpoint.

If you want to report errors from the browser, the report should pass through your own backend. The backend holds the private key, and only it forwards the data to the monitoring system.

What to do after a key leak?

If you suspect that a private key has been exposed, treat it like any other compromised credential. Revoke it, generate a new one and update your application's configuration.

Don't wait for confirmation of misuse. The mere fact that a secret ended up in a public repository, in logs, or in front-end code is reason enough to replace it.