> ## Documentation Index
> Fetch the complete documentation index at: https://sentrydocs.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# DSN & Keys

> Find your project DSN and understand Sentry authentication keys

## What is a DSN?

A **DSN** (Data Source Name) is the URL the Sentry SDK uses to send event data to the right project. Every Sentry project has at least one DSN. When you call `Sentry.init()`, the DSN tells the SDK where to deliver captures.

### DSN format

```
https://<public_key>@<host>.ingest.sentry.io/<project_id>
```

Example:

```
https://examplePublicKey@o0.ingest.sentry.io/0
```

| Component             | Description                                                             |
| --------------------- | ----------------------------------------------------------------------- |
| `examplePublicKey`    | Your project's public key. Identifies which project receives the event. |
| `o0.ingest.sentry.io` | The Sentry ingest host (may vary for self-hosted installations).        |
| `0`                   | The numeric project ID.                                                 |

<Note>
  The DSN is a **public key**, not a secret. It is safe to include in client-side JavaScript, mobile apps, and other code that users can read. What you should avoid is letting it be used to flood your project with spam — use rate limits and allowed domains to restrict it.

  Do not confuse the DSN with a Sentry **Auth Token**. Auth Tokens are secrets used for the API and source map uploads. Never put an Auth Token in your SDK `init` call.
</Note>

## Find your DSN

<Steps>
  <Step title="Open project settings">
    In Sentry, go to **Settings** → **Projects** and select your project.
  </Step>

  <Step title="Open Client Keys">
    In the left sidebar under the project settings, click **Client Keys (DSN)**.
  </Step>

  <Step title="Copy the DSN">
    Copy the DSN string from the **DSN** field. Paste it into your SDK `init` call.
  </Step>
</Steps>

## Multiple DSNs per project

You can create additional client keys for the same project. This is useful when:

* You want separate rate limits for different environments (production vs. staging).
* You want to disable ingestion for a specific deployment without changing code.
* You want to track which deployment is the source of events using key-level metadata.

To add a key, click **Add New Client Key** on the Client Keys page and give it a name.

## Restricting a DSN

Because the DSN is visible in client-side code, you should restrict what it can do.

### Rate limits

Set a per-key rate limit to cap the number of events Sentry accepts per minute. Events beyond the limit are dropped at ingestion. Configure this in **Client Keys (DSN)** by clicking **Configure** next to a key.

### Allowed domains (browser SDKs)

For browser-based SDKs, you can restrict a key so Sentry only accepts events that originate from specific domains. This prevents other sites from using your DSN to submit events to your project.

Under **Client Keys (DSN)** → **Configure**, add your domain patterns to the **Allowed Domains** list:

```
https://yourapp.com
https://*.yourapp.com
```

<Warning>
  Allowed domains are enforced by the Sentry ingest service, not the SDK. A determined attacker could still forge the `Origin` header. This is an abuse-prevention measure, not a security boundary.
</Warning>

## Rotating a DSN key

If a DSN has been compromised or abused, rotate it rather than deleting it immediately:

<Steps>
  <Step title="Create a new key">
    On the **Client Keys (DSN)** page, click **Add New Client Key**. Copy the new DSN.
  </Step>

  <Step title="Deploy the updated SDK config">
    Update your application's `Sentry.init()` call with the new DSN and deploy.
  </Step>

  <Step title="Delete the old key">
    Once the old deployment is gone or traffic has dropped to zero, delete the old key from the **Client Keys (DSN)** page.
  </Step>
</Steps>

<Tip>
  If you think your DSN was abused, also check **Settings** → **Usage & Billing** and review your ingest spike protection settings to prevent unexpected charges.
</Tip>

## Self-hosted Sentry

If you run self-hosted Sentry, the ingest host in your DSN will point to your own server instead of `ingest.sentry.io`. The format and behavior are the same.