Notify Bugsnag of an error or exception in web, mobile or desktop applications.
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 email@example.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!
View the API reference to get started.
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:
Your Bugsnag library should allow users to set the following settings in their application.
The apiKey for the project, this must be provided by the developer. You should send this value in the JSON Payload.
The current release stage for the application. Most platforms have a
sensible automatic way of obtaining this, for example
in rails apps, and this should be used if possible.
You should send this value in the JSON payload.
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.
If this is true, the plugin should notify Bugsnag of any uncaught exceptions (if possible). This should default to true.
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:
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.
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.
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