Understanding Sentry DSNs

When you’re integrating error tracking into your application, one of the first things you’ll encounter is the Data Source Name (DSN). If you’ve used Sentry before, you’re probably familiar with this term.

What Is a Sentry DSN?

A DSN tells the Sentry SDK where to send events and which project they belong to. It looks like a URL:

https://0123456789abcdef@yourcompany.bugsink.com/42

In this example:

  • yourcompany.bugsink.com identifies the server where the errors get sent
  • 42 is the project identifier
  • 0123456789abcdef is the “public” key for your project. (see below for why we use scare-quotes for that)

It’s additionally possible to have a DSN that has a path-fragment before the project identifier, but that’s quite uncommon in practice.

“Sentry DSN” is the usual name for this format, but Sentry-compatible servers such as Bugsink use it too.

DSN: public or private?

According to Sentry themselves, DSNs are basically public information:

DSNs are safe to keep public because they only allow submission of new events and related event data; they do not allow read access to any information. [..] While there is a risk of abusing a DSN, where any user can send events to your organization with any information they want, this is a rare occurrence.

Over at Bugsink, we have a slightly different take on this. While it is true that DSNs only allow the submission of new events, it does not follow that keeping DSNs public is the best default position.

Anyone with access to the public key can use it to pollute your project, consume event quota and, if you hook up an AI Agent to your stream of error events, even to attempt to influence that agent to take actions against your interests (“agent jacking”).

We say: Treat a DSN as a secret when you can. Keep it in environment variables or private configuration rather than publishing it or committing it to your repository.

For client-side applications (JavaScript, mobile or other native applications) this is something that’s unfortunately not possible, and for those cases the risks in the above paragraph are unavoidable. That does not mean it should be the default position, though.

How Does It Work?

  • Automatic Assignment: Sentry and Bugsink each assign a DSN when you create a project. You copy it from the project settings into your application’s SDK configuration.

SDK-side, you can configure the DSN in a few different ways:

  • Environment Variables: If the DSN isn’t directly provided, Sentry SDKs will attempt to read it from the SENTRY_DSN environment variable—except in environments like web browsers where this approach isn’t applicable.

  • Direct Configuration: You can also provide the DSN directly in your SDK configuration. This is the most common approach for web applications, where you can embed the DSN in your JavaScript code.

The DSN is the part of the SDK configuration that selects the error-tracking server. Because Bugsink implements Sentry’s ingestion protocol, an existing Sentry SDK can send events to Bugsink by changing only the DSN.

Test a DSN

Paste a Sentry or Bugsink DSN below to send one small, recognizable test event. The DSN stays in your browser, and the event goes directly to the server named in it. This page does not load the Sentry SDK (it’s just a few lines of JavaScript).