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___' });

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

Capturing Errors

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

try {
} catch (err) {

For additional functionality, see SDK Integrations.

Automatically Capturing 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

Automatically Capturing 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. You may want to disable default behavior by changing onunhandledrejection option to false in your GlobalHandlers integration and manually hook into such event handler and call Sentry.captureException or Sentry.captureMessage directly.

For example, the RSVP.js library (used by Ember.js) allows you to bind an event handler to a global error event.

RSVP.on('error', function(reason) {

Bluebird and other promise libraries report unhandled rejections to a global DOM event, unhandledRejection. In this case, you don’t need to do anything; we’ve already got you covered with the default GlobalHandlers integration and its onhandledrejection: true setting.

Please consult your promise library documentation on how to hook into its global unhandled rejection handler, if it exposes one.


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:

  • Apply source maps to receive the full benefit of error tracking and monitoring
  • 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.

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.


UglifyJS is a popular tool for minifying your source code for production. It can dramatically reduce the size of your files by eliminating whitespace, rewriting variable names, removing dead code branches, and more.

If you are using UglifyJS to minify your source code, the following command will additionally generate a source map that maps the minified code back to the original source:

uglifyjs app.js \
  -o \


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.

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.


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.

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.

Setting Context

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

Extra Context

In addition to the structured context that Sentry understands, you can send arbitrary key/value pairs of data 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.setExtra("character_name", "Mighty Fighter");

Unsetting Context

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

There are two different scopes for unsetting context — a global scope which Sentry does not discard at the end of an operation, and a scope that can be created by the user.

// This will be changed for all future events

// This will be changed only for the error caught inside and automatically discarded afterward
Sentry.withScope(scope => {

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

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

For more information, see:

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

Sentry implements a system it calls tags. Tags are various key/value pairs that get assigned to an event, and the user can later use them as a breakdown 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((scope) => {

or per event:

Sentry.withScope((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((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(err => {
        Sentry.withScope(scope => {
          scope.setFingerprint(['', 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(scope => {
  scope.setFingerprint(['Database Connection Error']);

Supported Browsers

Sauce Test Status

Advanced Usage

Advanced Configuration

The Sentry SDK sets the options when you first initialize the SDK.

  dsn: '___PUBLIC_DSN___',
  release: "28d497fb8af6cc3efbe160e28c1c08f08bd688fc",
  environment: 'staging',
  beforeSend: customPiiScrub(event),
  maxBreadcrumbs: 50,
  debug: true,

For more information, see:

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:

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 a whitelist of domains which might raise acceptable exceptions.

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

  whitelistUrls: [

There is also blacklistUrls 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
    blacklistUrls: [
      // 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((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.

But 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. Note that 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(() => {
    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(() => {
    // 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 blacklist/whitelist 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.

To configure it, use ignoreErrors, blacklistUrls, and whitelistUrls SDK options directly.


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.

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 * as Integrations from '@sentry/integrations';

  dsn: '___PUBLIC_DSN___',
  integrations: [new Integrations.ReportingObserver()]

Import name: 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: 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: 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: 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.

Available options:

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


Import name: Integrations.RewriteFrames

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

Available options:

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

Browser specific


Import name: 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 * as Integrations from '@sentry/integrations';

  dsn: '___PUBLIC_DSN___',
  integrations: [
    new Integrations.Vue({
      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-NEWge0n6G1Kne9yTAYJ/i9ezaKNstK9IbfJS7vlZk53XtWjF4wEJs3TOkC3hGGN1" crossorigin="anonymous"></script> -->
<script src="" integrity="sha384-/Cqa/8kaWn7emdqIBLk3AkFMAHBk0LObErtMhO+hr52CntkaurEnihPmqYj3uJho" 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: integrations => {
    // integrations will be all default integrations
    return integrations.filter(integration => !== 'Breadcrumbs');

Alternative way of setting an Integration

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

  dsn: '___PUBLIC_DSN___',
  integrations: integrations => {
    // integrations will be all default integrations
    return [...integrations, new MyCustomIntegration()];


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.

Additional Resources