Integrating the SDK

All our JavaScript-related SDKs provide the same API. Still, there are some differences between them, such as installation, which this section of the docs explains.

The quickest way to get started is to use the CDN hosted version of the JavaScript browser SDK:


You can also add the Sentry SDK as a dependency using npm:

$ npm install @sentry/browser

Connecting the SDK to Sentry

After you’ve completed setting up a project in Sentry, Sentry will give you a value which we call a DSN or Data Source Name. It looks a lot like a standard URL, but it’s just a representation of the configuration required by the Sentry SDKs. It consists of a few pieces, including the protocol, public key, the server address, and the project identifier.

You should init the Sentry Browser SDK as soon as possible during your page load:

// When using npm, import Sentry
import * as Sentry from '@sentry/browser';

Sentry.init({ dsn: '___PUBLIC_DSN___' });

For more configuration options, see:

Verifying Your Setup

Great! Now that you’ve completed setting up the SDK, maybe you want to quickly test out how Sentry works. Start by capturing an exception:

Sentry.captureException(new Error("Something broke"));

Then, you can see the error in your dashboard:

Error in Unresolved Issues with title This is my fake error message

The best way to deal with script-blocking extensions is to use the SDK package directly through the npm and bundle it with your application. This way, you can be sure, that the code will be always there as you expect it to be.

The second way is to download the SDK from our CDN and host it yourself, this way SDK will still be separated from the rest of your code, but you’ll be certain that it won’t be blocked, as it’s origin will be the same as the origin of your website.

You can easily fetch it using curl or any other similar tool:

$ curl -o sentry.browser.5.19.1.min.js -s

The last option, is to use Proxy guard, that will make sure that your code won’t break, even when you will call our SDK which was blocked. Proxy is supported by all browser except Internet Explorer, however there are no extensions in these browsers anyway. Also if Proxy is not in any of your user’s browser, it will be silently skipped, so you don’t have to worry about it breaking anything.

The snippet should be placed just above the tag containing our CDN bundle.

The snippet in a readable format presents like this:

if ("Proxy" in window) {
  var handler = {
    get: function(_, key) {
      return new Proxy(function(cb) {
        if (key === "flush" || key === "close") return Promise.resolve();
        if (typeof cb === "function") return cb(window.Sentry);
        return window.Sentry;
      }, handler);
  window.Sentry = new Proxy({}, handler);

And here is more useful, minified snippet, that you can copy-paste directly:

<script>if("Proxy"in window){var n={get:function(o,e){return new Proxy(function(n){return"flush"===e||"close"===e?Promise.resolve():"function"==typeof n?n(window.Sentry):window.Sentry},n)}};window.Sentry=new Proxy({},n)}</script>

Capturing Errors

Automatically and manually capture errors, exceptions, and rejections.

Automatically Capture Errors

By including and configuring Sentry, the SDK will automatically attach global handlers to capture uncaught exceptions and unhandled rejections.

Stack trace of a captured error

Note: Browsers may take security measures when serving script files from different origins that can block error reporting. If you find errors are not being reported accurately, please see the troubleshooting section on Cross-Origin Resource Sharing (CORS).

Manually Capture Errors

In most situations, you can capture errors manually with captureException().

try {
} catch (err) {

For additional functionality, see SDK Integrations.

Automatically Capture Errors with Promises

By default, Sentry for JavaScript captures unhandled promise rejections, as described in the official ECMAScript 6 standard.

Configuration may be required if you are using a third-party library to implement promises.

Most promise libraries have a global hook for capturing unhandled errors. Disable default behavior by changing the onunhandledrejection option to false in your GlobalHandlers integration and manually hook into each event handler and call Sentry.captureException or Sentry.captureMessage directly.


A release is a version of your code that you deploy to an environment. When you give Sentry information about your releases, you unlock many new features:

  • Determine the issue and regressions introduced in a new release
  • Predict which commit caused an issue and who is likely responsible
  • Resolve issues by including the issue number in your commit message
  • Receive email notifications when your code gets deployed

After configuring your SDK, setting up releases is a 2-step process:

  1. Create Release and Associate Commits
  2. Tell Sentry When You Deploy a Release

For more information, see Releases Are Better With Commits.

If you are using the Webpack Plugin releases will be automatically configured for you using the plugin’s release-lookup logic.

Source Maps

Sentry supports un-minifying JavaScript via source maps. This lets you view source code context obtained from stack traces in their original untransformed form, which is particularly useful for debugging minified code (e.g. UglifyJS), or transpiled code from a higher-level language (e.g. TypeScript, ES6).

When you’re using the Sentry JavaScript SDK, the SDK automatically fetches the source code and source maps by scraping the URLs within the stack trace. However, you may have legitimate reasons for disabling the JavaScript source fetching in Sentry.

Generating Source Maps

Most modern JavaScript transpilers support source maps. Below are instructions for some common tools.


Webpack is a powerful build tool that resolves and bundles your JavaScript modules into files fit for running in the browser. It also supports various loaders to transpile higher-level languages, reference stylesheets, or include static assets.

Webpack Plugin

We have created a convenient Webpack plugin that configures source maps and uploads them to Sentry during the build. This is the recommended way for uploading sources to Sentry. First, install the plugin via:

$ npm install --save-dev @sentry/webpack-plugin
$ yarn add --dev @sentry/webpack-plugin

To allow the plugin to upload source maps automatically, create a .sentryclirc or configure environment variables as described in the CLI configuration docs. Then, add the plugin to your webpack.config.js:

const SentryWebpackPlugin = require('@sentry/webpack-plugin');

module.exports = {
  // other configuration
  plugins: [
    new SentryWebpackPlugin({
      include: '.',
      ignoreFile: '.sentrycliignore',
      ignore: ['node_modules', 'webpack.config.js'],
      configFile: ''

Alternatively, if you prefer to upload source maps manually, Webpack needs to be configured to output source maps:

module.exports = {
    output: {
      path: path.join(__dirname, 'dist'),
      filename: "[name].js",
      sourceMapFilename: "[name]"
    // other configuration

In case you use SourceMapDevToolPlugin for more fine-grained control of source map generation, leave noSources turned off, so Sentry can display proper source code context in event stack traces.

Additionally, the webpack plugin will automatically set window.SENTRY_RELEASE, meaning your Sentry.init call will not need to be configured with the release key.


The TypeScript compiler can output source maps. Configure the sourceRoot property to / to strip the build path prefix from generated source code references. This allows Sentry to match source files relative to your source root folder:

    "compilerOptions": {
        "sourceMap": true,
        "inlineSources": true,
        "sourceRoot": "/"

Uploading / Hosting Source Maps

Source maps can be either:

  1. Uploaded directly to Sentry (recommended).
  2. Served publicly over HTTP alongside your source files.

Uploading Source Maps to Sentry

Except for Webpack, the recommended way to upload source maps is using Sentry CLI. If you have used Sentry Wizard to set up your project, it has already created all necessary configuration to upload source maps. Otherwise, follow the CLI configuration docs to set up your project. You can find the artifacts uploaded to Sentry by navigating to [Project] » Project Settings » Source Maps.

Now you need to set up your build system to create a release and attach the various source files. For Sentry to de-minify your stack traces you must provide both the minified files (e.g. app.min.js) and the corresponding source maps. In case the source map files do not contain your original source code (sourcesContent), you must additionally provide the original source files. (Alternatively, sentry-cli will automatically embed the sources (if missing) into your source maps if you pass the --rewrite flag.)

Sentry uses Releases to match the correct source maps to your events. To create a new release, run the following command (e.g. during publishing):

$ sentry-cli releases new <release_name>
$ sentry-cli releases files <release_name> upload-sourcemaps /path/to/files

This command will upload all files ending in .js and .map to the specified release. If you wish to change these extensions – e.g. to upload typescript sources – use the --ext option:

$ sentry-cli releases files <release_name> upload-sourcemaps --ext ts --ext map /path/to/files

Until now, the release is in a draft state (“unreleased”). Once all source maps have been uploaded, and your app has been published successfully, finalize the release with the following command:

$ sentry-cli releases finalize <release_name>

For convenience, you can alternatively pass the --finalize flag to the new command which will immediately finalize the release.

You don’t have to upload the source files (ref’d by source maps), but without them, the grouping algorithm will not be as strong, and the UI will not show any contextual source.

For more information, see Releases API documentation.

For more information, see:

Hosting Source Map Files

By default, Sentry will look for source map directives in your compiled JavaScript files, which are located on the last line and have the following format:

//# sourceMappingURL=<url>

When Sentry encounters such a directive, it will resolve the source map URL relative the source file in which it is found, and attempt an HTTP request to fetch it.

So for example, if you have a minified JavaScript file located at And in that file, on the last line, the following directive is found:


Sentry will attempt to fetch from

Alternatively, during source map generation you can specify a fully qualified URL where your source maps are located:

//# sourceMappingURL=

While making source maps available to Sentry from your servers is the most natural integration, it is not always advisable:

  • Sentry may not always be able to reach your servers.
  • If you do not specify versions in your asset URLs, there may be a version mismatch
  • The additional latency may mean that source mappings are not available for all errors.

For these reasons, it is recommended to upload source maps to Sentry beforehand (see below).

Adding Context

You can also set context when manually triggering events.

Sentry supports additional context with events. Often this context is shared among any issue captured in its lifecycle, and includes the following components:

Structured Contexts

Structured contexts are typically set automatically.


Information about the current actor.


Key/value pairs which generate breakdown charts and search filters.


An event’s severity.


A value used for grouping events into issues.

Unstructured Extra Data

Arbitrary unstructured data which the Sentry SDK stores with an event sample.

Capturing the User

Sending users to Sentry will unlock many features, primarily the ability to drill down into the number of users affecting an issue, as well as to get a broader sense about the quality of the application.

Capturing the user is fairly straight forward:

Sentry.setUser({"email": ""});

Users consist of a few critical pieces of information which are used to construct a unique identity in Sentry. Each of these is optional, but one must be present for the Sentry SDK to capture the user:


Your internal identifier for the user.


The user’s username. Generally used as a better label than the internal ID.


An alternative, or addition, to a username. Sentry is aware of email addresses and can show things like Gravatars, unlock messaging capabilities, and more.


The IP address of the user. If the user is unauthenticated, providing the IP address will suggest that this is unique to that IP. If available, we will attempt to pull this from the HTTP request data.

Additionally, you can provide arbitrary key/value pairs beyond the reserved names, and the Sentry SDK will store those with the user.

Tagging Events

Tags are key/value pairs assigned to events that can be used for breaking down issues or quick access to finding related events.

Most SDKs generally support configuring tags by configuring the scope:

Sentry.setTag("page_locale", "de-at");

Several common uses for tags include:

  • The hostname of the server
  • The version of your platform (e.g. iOS 5.0)
  • The user’s language

Once you’ve started sending tagged data, you’ll see it show up in a few places:

  • The filters within the sidebar on the project stream page.
  • Summarized within an event on the sidebar.
  • The tags page on an aggregated event.

We’ll automatically index all tags for an event, as well as the frequency and the last time the Sentry SDK has seen a value. Even more so, we keep track of the number of distinct tags and can assist you in determining hotspots for various issues.

Setting the Level

You can set the severity of an event to one of five values: fatal, error, warning, info, and debug. error is the default, fatal is the most severe and debug is the least severe.

To set the level out of scope, you can call captureMessage() per event:

Sentry.captureMessage('this is a debug message', 'debug');

To set the level within scope, you can call setLevel():

Sentry.configureScope(function(scope) { 

or per event:

Sentry.withScope(function(scope) {

Setting the Fingerprint

Sentry uses one or more “fingerprints” to decide how to group errors into issues.

For some very advanced use cases, you can override the Sentry default grouping using the fingerprint attribute. In supported SDKs, this attribute can be passed with the event information and should be an array of strings.

If you wish to append information, thus making the grouping slightly less aggressive, you can do that as well by adding the special string {{default}} as one of the items.

For more information, see Aggregate Errors with Custom Fingerprints.

Minimal Example

This minimal example will put all exceptions of the current scope into the same issue/group:

Sentry.configureScope(function(scope) {

The two common real-world use cases for the fingerprint attribute are demonstrated below:

Example: Split up a group into more groups (groups are too big)

Your application queries an external API service, so the stack trace is generally the same (even if the outgoing request is very different).

The following example will split up the default group Sentry would create (represented by {{default}}) further, while also splitting up the group based on the API URL.

function makeRequest(path, options) {
    return fetch(path, options).catch(function(err) {
        Sentry.withScope(function(scope) {
          scope.setFingerprint(['{{default}}', path]);

Example: Merge a lot of groups into one group (groups are too small)

If you have an error that has many different stack traces and never groups together, you can merge them together by omitting {{default}} from the fingerprint array.

Sentry.withScope(function(scope) {
  scope.setFingerprint(['Database Connection Error']);

Extra Context

In addition to the structured context that Sentry understands, you can send a key paired with a data object which the Sentry SDK will store alongside the event. These are not indexed, and the Sentry SDK uses them to add additional information about what might be happening:

Sentry.setContext("character_attributes", {
  name: "Mighty Fighter",
  age: 19,
  attack_type: "melee"

Passing Context Directly

Starting in version 5.16.0 of our JavaScript SDKs, some of the contextual data can be provided directly to captureException and captureMessage calls. Provided data will be merged with the one that is already stored inside the current scope, unless explicitly cleared using a callback method.

This functionality works in three different variations:

  • plain object containing updatable attributes
  • scope instance that we will extract the attributes from
  • callback function that will receive the current scope as an argument and allow for modifications

We allow the following context keys to be passed: tags, extra, contexts, user, level, fingerprint.

Example Usages

Sentry.captureException(new Error("something went wrong"), {
  tags: {
    section: "articles",
// Explicitly clear what has been already stored on the scope
Sentry.captureException(new Error("clean as never"), (scope) => {
  scope.setTag("clean", "slate");
  return scope;
// Use Scope instance to pass the data (its attributes will still merge with the global scope)
const scope = new Sentry.Scope();
scope.setTag("section", "articles");
Sentry.captureException(new Error("something went wrong"), scope);
// Use Scope instance to pass the data and ignore globally configured Scope attributes
const scope = new Sentry.Scope();
scope.setTag("section", "articles");
Sentry.captureException(new Error("something went wrong"), () => scope);

Unsetting Context

Context is held in the current scope and thus is cleared out at the end of each operation — request and so forth. You can also push and pop your own scopes to apply context data to a specific code block or function.

Sentry supports two different scopes for unsetting context:

  • a global scope, which Sentry does not discard at the end of an operation
  • a scope created by the user
// This will be changed for all future events

// This will be changed only for the error caught inside the `withScope` callback
// and automatically restored to the previous value afterward
Sentry.withScope(function(scope) {

If you want to remove globally configured data from the scope, you can call:

Sentry.configureScope(scope => scope.clear())

For more information, see:

Supported Browsers

Sauce Test Status

Advanced Usage

Sentry will automatically record certain events, such as changes to the URL and XHR requests to provide context to an error.

You can manually add breadcrumbs on other events or disable breadcrumbs.

// Example for an application that sometimes errors after the screen resizes

window.addEventListener('resize', function(event){
    category: 'ui',
    message: 'New window size:' + window.innerWidth + 'x' + window.innerHeight,
    level: 'info'

For more information, see:

Truncating strings on the event

After version 5.0.0 we introduced a new option called maxValueLength. The default value is 250 you can adjust this value according to your needs if your messages are longer than that. Please note that not every single value is affected by this option.

Filter Events & Custom Logic

Sentry exposes a beforeSend callback which can be used to filter out information or add additional context to the event object.

  beforeSend(event) {
    // Modify the event here
      // Don't send user's email address
    return event;

Decluttering Sentry

The first thing to do is consider constructing an allowed list of domains which might raise acceptable exceptions.

If your scripts are loaded from and your site is it’d be reasonable to set allowUrls to:

  allowUrls: [

There is also denyUrls if you want to block specific URLs forever.

The community has compiled a list of common ignore rules for everyday things, like Facebook, Chrome extensions, etc. So it’s recommended to at least check these out and see if they apply to you. Here is the original gist. This is not the default value of our SDK; it’s just a highlight of an extensive example of what it could be.

    ignoreErrors: [
      // Random plugins/extensions
      // See:
      'Can\'t find variable: ZiteReader',
      'jigsaw is not defined',
      'ComboSearch is not defined',
      // Facebook borked
      // ISP "optimizing" proxy - `Cache-Control: no-transform` seems to
      // reduce this. (thanks @acdha)
      // See
      // See
    denyUrls: [
      // Facebook flakiness
      // Facebook blocked
      // Woopra flakiness
      // Chrome extensions
      // Other plugins
      /127\.0\.0\.1:4001\/isrunning/i,  // Cacaoweb

For more information, see:

Capturing Messages

Typically, the Sentry SDK does not emit messages. This is most useful when you’ve overridden fingerprinting but need to give a useful message.

Sentry.captureMessage('Some message', level);

// Where `level` can be one of:
// 'fatal', 'error', 'warning', 'log', 'info, 'debug', 'critical'

Sentry.captureMessage('This shouldnt happen', 'info');

// or more explicit

Sentry.withScope(function(scope) {
  Sentry.captureMessage('This shouldnt happen');

For more information, see Setting the Level.

Lazy Loading Sentry

We recommend using our bundled CDN version for the browser as explained here. As noted there, if you want to use defer, you can, though keep in mind that any errors which occur in scripts that execute before the browser SDK script executes won’t be caught (because the SDK won’t be initialized yet). Therefore, if you do this, you’ll need to a) place the script tag for the browser SDK first, and b) mark it, and all of your other scripts, defer (but not async), which will guarantee that it’s executed before any of the others.

We also offer an alternative we call the Loader. You install by just adding this script to your website instead of the SDK bundle. This line is everything you need; the script is <1kB gzipped and includes the Sentry.init call with your DSN.

<script src="" crossorigin="anonymous"></script>

Select SDK version to load

If you go into the detail page (Configure button) of your DSN, you are able to select which SDK version the Loader should load.

It can take a few minutes until the change is visible in the code, since it’s cached.

What does the Loader provide?

It’s a small wrapper around our SDK. The Loader does a few things:

  • You will always have the newest recommended stable version of our SDK.
  • It captures all global errors and unhandled promise rejections.
  • It lazy injects our SDK into your website.
  • After you’ve loaded the SDK, the Loader will send everything to Sentry.

By default, the Loader contains all information needed for our SDK to function, like the DSN. In case you want to set additional options you have to set them like this:

Sentry.onLoad(function() {
    release: '1.0.0',
    environment: 'prod'

onLoad is a function that only the Loader provides; Loader will call it once Loader injects the SDK into the website. The Loader init() works a bit different, instead of just setting the options, we merge the options internally, only for convenience, so you don’t have to set the DSN again because the Loader already contains it.

As explained before, the Loader lazy loads and injects our SDK into your website but you can also tell the loader to fetch it immediately instead of only fetching it when you need it. Setting data-lazy to no will tell the Loader to inject the SDK as soon as possible:


The Loader also provides a function called forceLoad() which does the same, so that you can do the following:

  Sentry.onLoad(function() {
    // Use whatever Sentry.* function you want

Current limitations

As we inject our SDK asynchronously, we will only monitor global errors and unhandled promise for you until the SDK is fully loaded. That means that we might miss breadcrumbs during the download.

For example, a user clicking on a button on your website is making an XHR request. We will not miss any errors, only breadcrumbs and only up until the SDK is fully loaded. You can reduce this time by manually calling forceLoad or set data-lazy="no".

Collecting User Feedback

Sentry provides the ability to collect additional feedback from the user upon hitting an error. This is primarily useful in situations where you might generally render a plain error page (the classic 500.html). To collect the feedback, an embeddable JavaScript widget is available, which the Sentry SDK can show to your users on demand.

Modal popup asking user for more context on what occured before the break.

For more information, see:

SDK Integrations

All of Sentry’s SDKs provide Integrations, which provide additional functionality.

System integrations are integrations enabled by default that integrate into the standard library or the interpreter itself. They are documented so you can see what they do and that they can be disabled if they cause issues. To disable system integrations set defaultIntegrations: false when calling init(). To override their settings, provide a new instance with your config to integrations option. For example, to turn off browser capturing console calls: integrations: [new Sentry.Integrations.Breadcrumbs({ console: false })].

Default Integrations


Import name: Sentry.Integrations.InboundFilters

This integration allows developers to ignore specific errors based on the type or message, as well as deny/allow URLs that originate from the exception. It ignores errors, which message starts with Script error or Javascript error: Script error by default. More on this in our “What the heck is “Script error”?” blog post. Also, keep in mind that denying and allowing specific events, work only for captured exceptions, not raw message events.

To configure the integration, use ignoreErrors, denyUrls, and allowUrls SDK options directly. All three options accept an array of strings or RegExp patterns. When provided with a string, they’ll partially match the URL in case of denyUrls and allowUrls, or two variants in case of ignoreErrors - message itself, and ${type}: {message} format. When given RegExp, it will use the RegExp.test method instead, which you can use to achieve an exact match if desired.


Import name: Sentry.Integrations.FunctionToString

This integration allows the SDK to provide original functions and method names, even when our error or breadcrumbs handlers wrap them.

Browser specific


Import name: Sentry.Integrations.TryCatch

This integration wraps native time and events APIs (setTimeout, setInterval, requestAnimationFrame, addEventListener/removeEventListener) in try/catch blocks to handle async exceptions. By default, the Sentry SDK wraps all possible APIs.

Available options:

  setTimeout: boolean;             // Wrap `setTimeout` callback functions
  setInterval: boolean;            // Wrap `setInterval` callback functions
  requestAnimationFrame: boolean;  // Wrap `requestAnimationFrame` callback functions
  XMLHttpRequest: boolean;         // Wrap `XMLHttpRequest.send` callback functions
  eventTarget: boolean | string[]; // Wrap EventTarget API callback functions. Can provide an
                                   // array to only wrap callbacks on specific event targets. 
                                   // For a list of targets wrapped by default, see

Import name: Sentry.Integrations.Breadcrumbs

This integration wraps native APIs to capture breadcrumbs. By default, the Sentry SDK wraps all APIs.

Available options:

  beacon: boolean;  // Log HTTP requests done with the Beacon API
  console: boolean; // Log calls to `console.log`, `console.debug`, etc
  dom: boolean;     // Log all click and keypress events
  fetch: boolean;   // Log HTTP requests done with the Fetch API
  history: boolean; // Log calls to `history.pushState` and friends
  sentry: boolean;  // Log whenever we send an event to the server
  xhr: boolean;     // Log HTTP requests done with the XHR API

Import name: Sentry.Integrations.GlobalHandlers

This integration attaches global handlers to capture uncaught exceptions and unhandled rejections.

Available options:

  onerror: boolean;
  onunhandledrejection: boolean;

Import name: Sentry.Integrations.LinkedErrors

This integration allows you to configure linked errors. They’ll be recursively read up to a specified limit and lookup will be performed by a specific key. By default, the Sentry SDK sets the limit to 5 and the key used is cause.

Available options:

  key: string;
  limit: number;

Import name: Sentry.Integrations.UserAgent

This integration attaches user-agent information to the event, which allows us to correctly catalog and tag them with specific OS, Browser and version information.

Pluggable Integrations

Pluggable integrations are integrations that can be additionally enabled, to provide some very specific features. Sentry documents them so you can see what they do and that they can be enabled. To enable pluggable integrations, install @sentry/integrations package and provide a new instance with your config to integrations option. For example:

import * as Sentry from '@sentry/browser';
import { ReportingObserver as ReportingObserverIntegration } from '@sentry/integrations';

  dsn: '___PUBLIC_DSN___',
  integrations: [new ReportingObserverIntegration()]


Import name: Sentry.Integrations.ExtraErrorData

This integration extracts all non-native attributes from the Error object and attaches them to the event as the extra data.

Available options:

  depth: number; // limit of how deep the object serializer should go. Anything deeper then limit will be replaced with standard Node.js REPL notation of [Object], [Array], [Function] or primitive value. Defaults to 3.


Import name: Sentry.Integrations.CaptureConsole

This integration captures all Console API calls and redirects them to Sentry using captureMessage call. It then retriggers to preserve default native behaviour.

  levels: string[]; // an array of methods that should be captured, defaults to ['log', 'info', 'warn', 'error', 'debug', 'assert']


Import name: Sentry.Integrations.Dedupe

This integration deduplicates certain events. It can be helpful if you are receiving many duplicate errors. Be aware that we will only compare stack traces and fingerprints.


Import name: Sentry.Integrations.Debug

This integration allows you to inspect the content of the processed event, that will be passed to beforeSend and effectively send to the Sentry SDK. It will always run as the last integration, no matter when it was registered.

Available options:

  debugger: boolean; // trigger DevTools debugger instead of using console.log
  stringify: boolean; // stringify event before passing it to console.log


Import name: Sentry.Integrations.RewriteFrames

This integration allows you to apply a transformation to each frame of the stack trace. In the streamlined scenario, it can be used to change the name of the file frame it originates from, or it can be fed with an iterated function to apply any arbitrary transformation.

On Windows machines, you have to use Unix paths and skip the volume letter in root option in order to make it work. For example C:\\Program Files\\Apache\\www won’t work, however, /Program Files/Apache/www will.

Available options:

  root: string; // root path that will be appended to the basename of the current frame's url
  iteratee: (frame) => frame); // function that takes the frame, applies any transformation on it and returns it back

Browser specific


Import name: Sentry.Integrations.ReportingObserver

This integration hooks into the ReportingObserver API and sends captured events through to Sentry. It can be configured to handle only specific issue types.

Available options:

  types: <'crash'|'deprecation'|'intervention'>[];

Adding a custom Integration

import * as Sentry from '@sentry/browser';

// All integration that come with an SDK can be found on Sentry.Integrations object
// Custom integration must conform Integration interface:

  dsn: '___PUBLIC_DSN___',
  integrations: [new MyAwesomeIntegration()]

Adding Integration from @sentry/integrations

All pluggable / optional integrations do live inside @sentry/integrations.

import * as Sentry from '@sentry/browser';
import { Vue as VueIntegration } from '@sentry/integrations';

  dsn: '___PUBLIC_DSN___',
  integrations: [
    new VueIntegration({
      attachProps: true,

In case you are using the CDN version or the Loader, we provide a standalone file for every integration, you can use it like this:

<!-- Note that we now also provide a es6 build only -->
<!-- <script src="" integrity="sha384-ANLME5H29kJHTmQL8puury5rX/aVyOT7B+zNq8181MpYlV2dErr5fHbBdwwCJO+a" crossorigin="anonymous"></script> -->
<script src="" integrity="sha384-ibWewy8LWP0FdvEBD3iLjNmbFkkh/FKtOz8GR9C8ZBWjDTbjbdIDpa4nc/AasWns" crossorigin="anonymous"></script>

<!-- If you include the integration it will be available under Sentry.Integrations.Vue -->
<script src="" crossorigin="anonymous"></script>

    dsn: '___PUBLIC_DSN___',
    integrations: [
      new Sentry.Integrations.Vue({
        attachProps: true,

Removing an Integration

In this example, we will remove the by default enabled integration for adding breadcrumbs to the event:

import * as Sentry from '@sentry/browser';

  dsn: '___PUBLIC_DSN___',
  integrations: function(integrations) {
    // integrations will be all default integrations
    return integrations.filter(function(integration) {
      return !== 'Breadcrumbs';


Event and Breadcrumb hints are objects containing various information used to put together an event or a breadcrumb. For events, those are things like event_id, originalException, syntheticException (used internally to generate cleaner stack trace), and any other arbitrary data that user attaches. For breadcrumbs, it’s all implementation dependent. For XHR requests, the hint contains the xhr object itself, for user interactions it contains the DOM element and event name, etc.

They are available in two places: beforeSend/beforeBreadcrumb and eventProcessors. Those are two ways we’ll allow users to modify what we put together.

Hints for Events


The original exception that caused the Sentry SDK to create the event. This is useful for changing how the Sentry SDK groups events or to extract additional information.


When a string or a non-error object is raised, Sentry creates a synthetic exception so you can get a basic stack trace. This exception is stored here for further data extraction.

Hints for Breadcrumbs


For breadcrumbs created from browser events, the Sentry SDK often supplies the event to the breadcrumb as a hint. This, for instance, can be used to extract data from the target DOM element into a breadcrumb.

level / input

For breadcrumbs created from console log interceptions. This holds the original console log level and the original input data to the log function.

response / input

For breadcrumbs created from HTTP requests. This holds the response object (from the fetch API) and the input parameters to the fetch function.

request / response / event

For breadcrumbs created from HTTP requests. This holds the request and response object (from the node HTTP API) as well as the node event (response or error).


For breadcrumbs created from HTTP requests done via the legacy XMLHttpRequest API. This holds the original xhr object.


CORS Attributes and Headers

To gain visibility into a JavaScript exception thrown from scripts originating from different origins, do two things:

  1. Add a crossorigin=”anonymous” script attribute

     <script src="" crossorigin="anonymous"></script>

    The script attribute tells the browser to fetch the target file “anonymously.” Potentially user-identifying information like cookies or HTTP credentials won’t be transmitted by the browser to the server when requesting this file.

  2. Add a Cross-Origin HTTP header

     Access-Control-Allow-Origin: *

    Cross-Origin Resource Sharing (CORS) is a set of APIs (mostly HTTP headers) that dictate how files ought to be downloaded and served across origins.

    By setting Access-Control-Allow-Origin: *, the server is indicating to browsers that any origin can fetch this file. Alternatively, you can restrict it to a known origin you control:


    Most community CDNs properly set an Access-Control-Allow-Origin header.

     $ curl --head | \
     grep -i "access-control-allow-origin"
     Access-Control-Allow-Origin: *

Additional Resources