Error reporting API

Notify Bugsnag of an error or exception in web, mobile or desktop applications.

Error reporting libraries

Check out our platform guides to see if an error reporting library
already exists for your platform.

If there is no library available for the language or framework you are using,
then why not write one yourself? Email us at
notifiers@bugsnag.com to let us know about
your new notifier, and we will make it available to other Bugsnag users. We
will even give you special Bugsnag perks to say thank you!

API reference

Library configuration

When writing a notifier library, you should consider providing methods to allow
users to configure how errors are sent to bugsnag.

On our official libraries, we provide the following interfaces:

Application settings

Your Bugsnag library should allow users to set the following settings in
their application.

apiKey

The apiKey for the project, this must be provided by the developer.
You should send this value in the JSON Payload.

releaseStage

The current release stage for the application. Most platforms have a
sensible automatic way of obtaining this, for example RAILS_ENV
in rails apps, and this should be used if possible.
You should send this value in the JSON payload.

notifyReleaseStages

A list of release stages that the notifier will capture and send errors
for. If the current release stage is not in this list, errors should not
be sent to Bugsnag.

autoNotify

If this is true, the plugin should notify Bugsnag of any uncaught
exceptions (if possible). This should default to true.

Per-session settings

You should also allow developers to set the following settings on a
per-request or per-session basis. These settings allow us to attach
meta-data to each error:

user

An object representing the current application’s user, which can include ID,
email address, and username. Many platforms have a way to automatically fill
this, for example session data in rails apps. You could also generate a
UUID and store this on the user’s device or in their session. Even if you
automatically choose a user.id, you should still allow developers to set one
themselves. You should send this value in the JSON payload.

context

Allow the developer to set the context that is currently active in the
application. You should default this to something sensible for the platform,
for example “action#controller” in a rails app. You should send this value
in the JSON payload.

metaData

Allow the developer to set any extra data that will be sent as meta-data
along with every error. You should send this value inside metaData in the
JSON payload.