Authentication

DSN format, authentication headers, and HTTP conventions for communicating with Sentry.

SDKs are encouraged to allow arbitrary options via the constructor, but must allow the first argument as a DSN string. This string contains the following bits:

Copied
'{PROTOCOL}://{PUBLIC_KEY}:{SECRET_KEY}@{HOST}{PATH}/{PROJECT_ID}'

The final endpoint you'll be sending requests to is constructed per the following:

Copied
 {BASE_URI} = '{PROTOCOL}://{HOST}{PATH}'

'{BASE_URI}/api/{PROJECT_ID}/{ENDPOINT}/'

Within the HOST segment you will find the ingest domain for your organization. For self-hosted instances this will be the base host of your instance, and for sentry.io it will contain a host in the pattern of o{orgid}.ingest.{region}.sentry.io. For US based accounts o{orgid}.ingest.sentry.io will also work.

Sentry provides the following endpoints:

  • /envelope/ for any submission using Envelopes.
  • /minidump/ for multipart requests containing Minidumps.
  • /unreal/ for Unreal Engine 4 crash reports.
  • /playstation/ for PlayStation crash reports.
  • /security/ for Browser CSP reports, usually configured in a browser instead of an SDK.

See the respective endpoints for information on how to compose proper request payloads.

For example, given the following constructor:

Copied
Sentry.init({ dsn: "https://public@sentry.example.com/1" });

You should parse the following settings:

  • URI = https://sentry.example.com
  • Public Key = public
  • Project ID = 1

The resulting POST request for a plain JSON payload would then transmit to:

Copied
'https://sentry.example.com/api/1/store/'

An authentication header is expected to be sent along with the message body, which acts as an ownership identifier:

Copied
X-Sentry-Auth: Sentry sentry_version=7,
  sentry_client=<client version, arbitrary>,
  sentry_key=<public api key>,
  sentry_secret=<secret api key>

The sentry_secret must only be included if a secret key portion was contained in the DSN. Future versions of the protocol will fully deprecate the secret key.

In situations where it's not possible to send the custom X-Sentry-Auth header, it's possible to send these values via the querystring:

Copied
?sentry_version=7&sentry_key=<public api key>&sentry_secret=<secret api key>...
sentry_key
Required. The public key which should be provided as part of the SDK configuration.
sentry_version
Required. The protocol version. The current version of the protocol is 7.
sentry_client
Recommended. An arbitrary string that identifies your SDK, including its version. The typical pattern for this is client_name/client_version. For example, the Python SDK might send this as sentry.python/1.0.
sentry_timestamp
The unix timestamp representing the time at which this event was generated. This key is effectively deprecated, and it is ignored on the receiving side. Use the sent_at envelope header instead.
sentry_secret
The secret key which should be provided as part of the SDK configuration. This key is effectively deprecated, and no longer needs to be set. However, since it was required in older versions, it should still be allowed and passed through to Sentry if set.

We recommend always sending the following headers:

  • content-type
  • content-length
  • user-agent

The following additional headers are permitted as per CORS policy:

  • x-sentry-auth
  • x-requested-with
  • x-forwarded-for
  • origin
  • referer
  • accept
  • authentication
  • authorization
  • content-encoding
  • transfer-encoding

All SDKs are expected to report their name and version via the user-agent header. The following format should be used (unless required or recommended differently by the platform, e.g. for browser SDKs, where the user agent header must be set by the browser itself):

{sdk-name}/{sdk-version}

For example:

  • sentry.python/1.45.0
  • sentry.php/4.7.0
  • sentry-ruby/5.17.3
  • sentry.cocoa/8.24.0

Additional information about the runtime, operating system, and others can be appended as comments in parentheses, separated by ; (semicolon and space), like so:

{sdk-name}/{sdk-version} ({runtime-name} {runtime-version}; {os-name} {os-version})

There is no expectation towards the presence or order of fields. The user agent must not contain PII or otherwise sensitive data. In general it should not contain any information that is not already present in the payload.

Was this helpful?
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").