Sending reports

Send a batch of Events to Rollbar using a single HTTP request.

The API Key associated with the project. Informs Bugsnag which project has generated this error.

Construct an ApiKey value.

The payload of a POST request to https://notify.bugsnag.com/

A default report.

The API Key associated with the project. Informs Bugsnag which project has generated this error. This is provided for legacy notifiers. It is preferable to use the Bugsnag-Api-Key header instead.

The version number of the payload. This is currently 5. The Bugsnag-Payload-Version header should be included as well, for compatibility reasons.

Describes the notifier itself. These properties are used within Bugsnag to track error rates from a notifier.

An array of error events that Bugsnag should be notified of. A notifier can choose to group notices into an array to minimize network traffic, or can notify Bugsnag each time an event occurs.

An array of error events that Bugsnag should be notified of. A notifier can choose to group notices into an array to minimize network traffic, or can notify Bugsnag each time an event occurs.

A default event.

An array of exceptions that occurred during this event. There must be at least one entry. Most of the time there will only be one exception, but some languages support "nested" or "caused by" exceptions. In this case, exceptions should be unwrapped and added to the array one at a time. The first exception raised should be first in this array.

An array of user- and system-initiated events which led up to an error, providing additional context. This list is sequential and ordered newest to oldest.

Details about the web request from the client that experienced the error, if relevant. To display custom request data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in a request object.

An array of background threads. This is optional but recommended for apps that rely heavily on threading. Threads should be in an order that makes sense for your application.

A string representing what was happening in the application at the time of the error. This string could be used for grouping purposes, depending on the event. Usually this would represent the controller and action in a server based project. It could represent the screen that the user was interacting with in a client side project. For example: - On Ruby on Rails the context could be controller#action. - In Android, the context could be the top most Activity. - In iOS, the context could be the name of the top most UIViewController.

Bugsnag's default error grouping can be overridden by specifying a custom grouping hash.

Whether the error was unhandled. If true, the error was detected by the notifier because it was not handled by the application. If false, the errors was handled and reported using Bugsnag.notify.

The severity of the error

Information about why the severity was picked.

Information about the user affected by the error. These fields are optional but highly recommended. To display custom user data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in a user object.

Information about the app where the error occurred. These fields are optional but highly recommended. To display custom app data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in an app object.

Information about the computer/device running the app. These fields are optional but highly recommended. To display custom device data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in a device object.

Details of any session information associated with the event. This can be used alongside the Bugsnag Session Tracking API to associate the event with a session so that a release's crash rate can be determined.

An object containing any further data you wish to attach to this error event. This should contain one or more objects, with each object being displayed in its own tab on the event details on Bugsnag.

An exception that occurred during this event.

A default exception.

The class of error which occurred. This field is used to group the errors together so should not contain any contextual information that would prevent correct grouping. This would ordinarily be the Exception name when dealing with an exception.

The error message associated with the error. Usually this will contain some information about this specific instance of the error and is not used to group the errors.

An array of stackframe objects. Each object represents one line in the exception's stacktrace. Bugsnag uses this information to help with error grouping, as well as displaying it to the user.

This should be set for the following platforms so that the stacktrace can be parsed correctly:

Each stackrame represents one line in the exception's stacktrace. Bugsnag uses this information to help with error grouping, as well as displaying it to the user.

A default stackFrame.

The file that this stack frame was executing. It is recommended that you strip any unnecessary or common information from the beginning of the path.

The line of the file that this frame of the stack was in.

The column of the file that this frame of the stack was in.

The method that this particular stack frame is within.

If this stacktrace line is in the user's project code, set this to true. It is useful for developers to be able to see which lines of a stacktrace are within their own application, and which are within third party libraries. This boolean field allows Bugsnag to display this information in the stacktrace as well as use the information to help group errors better.

The code in this file surrounding this line. This is an object containing key value pairs where each key is a line number and each value is the code from that line. You can include up to three lines on either side of the line where the error occurred. These will be displayed on the bugsnag dashboard when you expand that line.

User- and system-initiated event which led up to an error, providing additional context.

A default breadcrumb.

The time at which the event occurred, in ISO 8601 format.

A short summary describing the event, such as the user action taken or a new application state.

A category which describes the breadcrumb, from the list of allowed values.

Additional information about the event, as key/value pairs.

Details about the web request from the client that experienced the error, if relevant. To display custom request data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in a request object.

A default request.

The IP address of the client that experienced the error.

The headers sent with the request.

The HTTP method used.

The URL of the request.

The HTTP referer

An array of background threads. This is optional but recommended for apps that rely heavily on threading. Threads should be in an order that makes sense for your application.

A default thread.

The id of the thread in your application.

A human readable name for the thread.

If this is the thread that the error was reported from (either an unhandled error or a call to bugsnag.notify), set this to true.

An array of stacktrace objects. Each object represents one line in the stacktrace of the thread at the point that the error occurred.

Setting this allows the stacktrace to be parsed correctly.

Information about why the severity was picked.

A default severityReason.

A type key that represents the reason for the assigned severity.

Optional attributes to provide extra information about the severity reason.

Optional attributes to provide extra information about the severity reason.

A default severityReasonAttributes.

Included for unhandledError severity reason. See PHP Error Constants.

Included for log severity reason.

Included for signal severity reason. See Signal Codes.

Included for strictMode severity reason. See Strict Mode.

Included for errorClass severity reason. Specifies the error class that is automatically sent.

Information about the user affected by the error. These fields are optional but highly recommended. To display custom user data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in a user object.

A default user.

A unique identifier for a user affected by this event. This could be any distinct identifier that makes sense for your application/platform.

The user's name, or a string you use to identify them.

The user's email address.

Information about the app where the error occurred. These fields are optional but highly recommended. To display custom app data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in an app object.

A default app.

A unique ID for the application.

The version number of the application which generated the error.

The version code of the application (Android only)

The bundle version/build number of the application (iOSmacOStvOS only)

A unique identifier to identify a code bundle release when using tools like CodePush (mobile only).

A build ID that is required to identify a specific build when the version and version code are the same.

The release stage that this error occurred in, for example "development", "staging" or "production".

A specialized type of the application, such as the worker queue or web framework used, like "rails", "mailman", or "celery".

The UUIDs of the debug symbols file corresponding to this application, if any.

How long the app has been running for in milliseconds.

How long the app has been in the foreground of the device in milliseconds.

Whether or not the app was in the foreground when the error occurred.

The architecture of the running binary (Android only).

Information about the computer/device running the app. These fields are optional but highly recommended. To display custom device data alongside these standard fields on the Bugsnag website, the custom data should be included in the metaData object in a device object.

A default device.

The hostname of the server running your code, if applicable.

A unique identifier for the device.

The manufacturer of the device.

The model of the device.

The model number of the device.

The device's operating system name.

The device's operating system version.

The number of bytes unused in the device's RAM.

The number of total bytes in the device's RAM.

The number of unused bytes on the drive running the application.

If a web application, the web browser used by the device.

If a web application, the version of the browser used by the device.

Whether or not the device has been modified to give users root access.

The orientation of the device at the time of the error.

The time at which the error occurred, in ISO 8601 format.

The ABIs supported by the device (Android only).

The versions of the relevant runtimes, languages and/or frameworks for the platform.

The versions of the relevant runtimes, languages and/or frameworks for the platform.

A default runtimeVersions.

The Android API level (Android only).

Bottle framework version (Python only).

Celery task queue version (Python only).

Clang compiler version (iOStvOSmacOS only).

Cocos2d-x framework version (Cocos2d-x only).

Delayed Job framework version (Ruby only).

Django framework version (Python only).

Description of the framework (.NET only).

.NET API compatibility level (Unity only).

Version of .NET Common Language Runtime (.NET only).

.NET scripting runtime version (Unity only).

EventMachine library version (Ruby only).

Expo app version (Expo only).

Expo SDK version (Expo only).

Flask framework version (Python only).

Gin framework version (Go only).

Go language version (Go only).

Java platform implementation type (Java only).

Java platform implementation type (Java only).

Version of JRuby (Ruby only).

Laravel framework version (PHP only).

Lumen framework version (PHP only).

Magento platform version (PHP only).

Mailman framework version (Ruby only).

Martini framework version (Go only).

Negroni framework version (Go only).

Node.js version (Javascript only).

Build number of the OS (iOStvOSmacOS only).

Version of PHP (PHP only).

Version of Python (Python only).

Que job queue version (Ruby only).

Rack webserver version (Ruby only).

Ruby on Rails version (Ruby only).

Rake tool version (Ruby only).

Version of React Native (React Native/Expo only).

Javascript engine type (React Native/Expo only).

Resque library version (Ruby only).

Revel framework version (Go only).

Version of Ruby (Ruby only).

Shoryoken framework version (Ruby only).

Sidekiq scheduler version (Ruby only).

Silex framework version (PHP only).

Sinatra DSL version (Ruby only).

Spring Boot framework version (Java only).

Spring framework version (Java only).

Swift language version (iOStvOSmacOS only).

Symfony framework version (PHP only).

Tornado framework version (Python only).

Version of Unity.

The Unity scripting backend - Mono or IL2CPP (Unity only).

Wordpress version (PHP only).

Details of any session information associated with the event. This can be used alongside the Bugsnag Session Tracking API to associate the event with a session so that a release's crash rate can be determined.

A default session.

The unique identifier of the session.

The time (in ISO 8601 format) at which the session started.

Details of the number of handled and unhandled events that have occurred so far in this session.

Details of the number of handled and unhandled events that have occurred so far in this session.

A default sessionEvents.

Details of the number of handled and unhandled events that have occurred so far in this session.

The number of unhandled events that have occurred in this session (including this event)

The version number of the payload. This is currently 5. The Bugsnag-Payload-Version header should be included as well, for compatibility reasons.

This API only supports payload version 5.

Describes the notifier itself. These properties are used within Bugsnag to track error rates from a notifier.

Information describing the notifier in this module.

This should be set for the following platforms so that the stacktrace can be parsed correctly:

For cocoa (iOStvOSmacOS)

For android

For browser-based JavaScript

For JavaScript in Expo

For JavaScript in Node

A category which describes the breadcrumb, from the list of allowed values.

Changing screens or content being displayed, with a defined destination and optionally a previous location.

Sending and receiving requests and responses.

Performing an intensive task or query.

Messages and severity sent to a logging platform.

Actions performed by the user, like text input, button presses, or confirming/cancelling an alert dialog.

Changing the overall state of an app, such as closing, pausing, or being moved to the background, as well as device state changes like memory or battery warnings and network connectivity changes.

An error which was reported to Bugsnag encountered in the same session.

User-defined, manually added breadcrumbs.

Used for parsing the stack trace correctly.

For cocoa (iOStvOSmacOS)

For android

For browser-based JavaScript

The severity of the error