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

View the API reference to get started.

Error Reporting 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, 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.