Skip to main content

Bugsnag Data Source

The Bugsnag connector enables you to ingest error monitoring data from your Bugsnag organization, including errors, events, projects, collaborators, and stability metrics. Follow the instructions below to create a new data flow that ingests data from a Bugsnag source in Nexla.
bugsnag_api.png

Bugsnag

Create a New Data Flow

  1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

  2. Select the Bugsnag connector tile from the list of available connectors. Then, select the credential that will be used to connect to the Bugsnag instance, and click Next; or, create a new Bugsnag credential for use in this flow.

  3. In Nexla, Bugsnag data sources can be created using pre-built endpoint templates, which expedite source setup for common Bugsnag endpoints.

Configure Using a Template

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Bugsnag endpoints. Each template is designed specifically for the corresponding Bugsnag endpoint, making data source setup easy and efficient.

Endpoint Settings

  • Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

    List Organizations

    Retrieve all organizations associated with the authenticated user account.

    • Endpoint: GET https://api.bugsnag.com/user/organizations
    • Data path: $[*]

    All parameters are optional; omitting filters returns all available records.

    List Projects

    Retrieve all projects for a given organization.

    • Endpoint: GET https://api.bugsnag.com/organizations/{parameter}/projects
    • Data path: $[*]
    • Organization ID (Required): The Bugsnag organization ID to retrieve projects for.

    The Organization ID parameter is required to identify the specific resource to retrieve.

    List Errors

    Retrieve error groups for a project with optional status and date filters.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/errors?status={parameter}&sort={parameter}
    • Data path: $[*]
    • Project ID (Required): The Bugsnag project ID to retrieve errors for.
    • Status (Optional): Filter errors by status. Accepted values: 'open', 'fixed', 'ignored', 'snoozed'.
    • Sort (Optional): Sort errors by field. Accepted values: 'events', 'users', 'last_seen', 'first_seen'.

    The Project ID parameter is required to identify the specific resource to retrieve.

    List Events for Error

    Retrieve individual error event occurrences for a specific error group.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/errors/{parameter}/events
    • Data path: $[*]
    • Project ID (Required): The Bugsnag project ID.
    • Error ID (Required): The Bugsnag error group ID to retrieve events for.

    The Project ID parameter is required to identify the specific resource to retrieve.

    List Releases

    Retrieve application release history for a project including build metadata and error rates.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/releases
    • Data path: $[*]
    • Project ID (Required): The Bugsnag project ID to retrieve releases for.

    The Project ID parameter is required to identify the specific resource to retrieve.

    List Collaborators

    Retrieve all collaborators (team members) for an organization.

    • Endpoint: GET https://api.bugsnag.com/organizations/{parameter}/collaborators
    • Data path: $[*]
    • Organization ID (Required): The Bugsnag organization ID to retrieve collaborators for.

    The Organization ID parameter is required to identify the specific resource to retrieve.

    List Stability Trend

    Retrieve application stability trend data showing session and error rates over time.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/stability_trend
    • Data path: $.buckets[*]
    • Project ID (Required): The Bugsnag project ID to retrieve stability data for.

    The Project ID parameter is required to identify the specific resource to retrieve.

    Get Pivot Report

    Retrieve aggregated error event counts grouped by a specified dimension (e.g., app version, OS, user).

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/pivot/trend?dimension={parameter}
    • Data path: $.data[*]
    • Project ID (Required): The Bugsnag project ID to generate the pivot report for.
    • Dimension (Optional): The dimension to pivot by. Accepted values: 'app_version', 'os_version', 'user_id', 'context'.

    The Project ID parameter is required to identify the specific resource to retrieve.

    List Event Fields

    Retrieve available custom metadata field keys observed in error events for a project.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/event_fields
    • Data path: $[*]
    • Project ID (Required): The Bugsnag project ID to retrieve event fields for.

    The Project ID parameter is required to identify the specific resource to retrieve.

    List Trends

    Retrieve error event volume trend data over time for a project for monitoring error rates.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}/trend
    • Data path: $.data[*]
    • Project ID (Required): The Bugsnag project ID to retrieve trend data for.

    The Project ID parameter is required to identify the specific resource to retrieve.

    Get Project

    Retrieve detailed configuration and metadata for a specific Bugsnag project.

    • Endpoint: GET https://api.bugsnag.com/projects/{parameter}
    • Data path: $
    • Project ID (Required): The Bugsnag project ID to retrieve details for.

    The Project ID parameter is required to identify the specific resource to retrieve.

Endpoint Testing

Once the selected endpoint template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually

Bugsnag sources can be manually configured to ingest data from any valid Bugsnag Data Access API endpoint. Configuration options available for Bugsnag sources allow them to be fully customized to suit any use case — including using chained API calls to fetch data from multiple endpoints or sources that require custom request parameters.

The Bugsnag Data Access API base URL is https://api.bugsnag.com. All endpoints require authentication via the Personal Auth Token configured in your Bugsnag credential.

First, select the method that will be used for API calls from the Method pulldown menu. The most common method for Bugsnag data retrieval is:

  • GET: For retrieving errors, events, projects, organizations, and other Bugsnag resources

API Endpoint URL

  1. Enter the URL of the Bugsnag API endpoint from which this source will fetch data in the Set API URL field. This should be the complete URL including the protocol (https://) and any required path parameters.

    Common Bugsnag Data Access API endpoint URL patterns include:

    • List organizations: https://api.bugsnag.com/user/organizations
    • List projects in an organization: https://api.bugsnag.com/organizations/{'{organization_id}'}/projects
    • List errors in a project: https://api.bugsnag.com/projects/{'{project_id}'}/errors
    • List events for an error: https://api.bugsnag.com/projects/{'{project_id}'}/errors/{'{error_id}'}/events
    • List collaborators: https://api.bugsnag.com/organizations/{'{organization_id}'}/collaborators
    • Get stability scores: https://api.bugsnag.com/projects/{'{project_id}'}/stability_score

    Replace {'{organization_id}'}, {'{project_id}'}, and {'{error_id}'} with the appropriate IDs from your Bugsnag account. Organization and project IDs can be found in the Bugsnag dashboard URLs or retrieved programmatically by first calling the /user/organizations endpoint.

Ensure the API endpoint URL is correct and accessible with your current credentials. You can test the endpoint using the Test button after configuring the URL. For a complete list of available Bugsnag Data Access API endpoints, refer to the Bugsnag API reference.

Date/Time Macros (API URL)

Optional

Optionally, the API URL can be customized using macros — all macros added to the API URL will be converted into values when Nexla executes the API call. Macros are dynamic placeholders that allow you to create flexible API endpoints that can adapt to different time periods or data requirements.

Date/time macros are particularly useful for Bugsnag endpoints that support filtering by date, such as fetching errors or events within a specific time window. For example, you can use macros to construct query parameters like ?filters[event.since][][type]=eq&filters[event.since][][value]={'{now-1}'} to retrieve errors reported since the previous time period.

  1. To add a macro, type { at the appropriate position in the API URL (within the Set API URL field), and select the desired macro from the dropdown list.

    • {now} – The current datetime
    • {now-1} – The datetime one time unit before the current datetime
    • {now+1} – The datetime one time unit after the current datetime
    • custom – Datetime macros can reference any number of time units before or after the current datetime — for example, enter (now-4) to indicate the datetime four time units before the current datetime
  2. Select the format that will be applied to datetime macros from the Date Format for Date/Time Macro pulldown menu. This format will be applied to the base datetime value of the macro — i.e., the value of {now} in {now-1}. The Bugsnag API accepts ISO 8601 date-time format (e.g., yyyy-MM-dd'T'HH:mm:ssZ).

  3. Select the datetime unit that will be used to perform mathematical operations in the included macro(s) from the Time Unit for Operations pulldown menu — for example, for the macro {now-1}, when Day is selected, {now-1} will be converted to the datetime one day before the current datetime.

Lookup-Based Macros (API URL)

Optional

Column values from existing lookups can also be included as macros in the API URL. Lookup-based macros allow you to reference data from previously configured data sources or lookups, enabling dynamic API endpoints that can adapt based on existing data.

Lookup-based macros are useful when you need to create Bugsnag API endpoints that reference specific organization IDs, project IDs, or error IDs retrieved from a prior data source in your Nexla environment. For example, you can chain a lookup on /user/organizations to dynamically populate the organization_id in a subsequent projects or errors endpoint URL.

  1. To include a lookup column value macro, select the relevant lookup from the Add Lookups to Supported Macros pulldown menu.

  2. Type { at the appropriate position in the API URL, and select the lookup column-based macro from the dropdown list. Lookup-based macros are automatically populated into the macro list when a lookup is selected in the Add Lookups to Supported Macros pulldown menu.

Path to Data

Optional

If only a subset of the data returned by the Bugsnag API endpoint is needed, you can designate the part of the response that should be included in the Nexset(s) produced from this source by specifying the path to the relevant data within the response. This is particularly useful because Bugsnag API responses often wrap returned records in a top-level array or object alongside metadata.

For example, when fetching a list of errors from a project, the Bugsnag API returns a JSON array of error objects. By entering the path to the relevant data, you can configure Nexla to treat each element of the returned array as an individual record.

Path to Data is essential when Bugsnag API responses have nested structures. The Bugsnag Data Access API typically returns arrays of resource objects at the top level for list endpoints (e.g., $[*] for a root-level array), and nested objects for detail endpoints.

  • To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

    • For responses in JSON format enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (e.g., $[*] to access a top-level array, or $.data.items[*] to access an array nested inside a data object).
    Path to Data Example:

    Most Bugsnag list endpoints return a top-level JSON array. For example, the /organizations/{'{organization_id}'}/projects endpoint returns a JSON array of project objects. In this case, the path to the relevant data would be entered as $[*].

Autogenerate Path Suggestions

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

  • To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the API endpoint. Suggested data paths generated based on the content & format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

  • Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

    PathSuggestions.png

Metadata

If metadata is included in the response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. This is useful when you want to preserve important contextual information that applies to all records but isn't part of the main data array.

The Bugsnag API includes pagination metadata in the Link response header, and some endpoints return summary metadata alongside the primary data payload. For any metadata embedded in the JSON response body, specify its path here.

Metadata paths are particularly useful for preserving Bugsnag API response context like total event counts, pagination details, or request timestamps that apply to all records in the response.

  • To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

    • For responses in JSON format, enter the JSON path to the object or array that contains the metadata.

Request Headers

Optional
  • If Nexla should include any additional request headers in API calls to this source, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2).

    Common additional headers for the Bugsnag Data Access API include:

    • X-Version: Specify the API version (e.g., 2) if required for a particular endpoint
    • Accept: Specify the desired response format (e.g., application/json)

    You do not need to include the Authorization header here — it is automatically applied by Nexla from your Bugsnag credential. Common headers like Content-Type and Accept are typically handled automatically by Nexla based on your credential configuration.

Endpoint Testing

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

The Bugsnag Data Access API enforces rate limits. If a test request fails with an HTTP 429 response, the rate limit window (1 minute) has been exceeded. The response includes X-RateLimit-Limit and X-RateLimit-Remaining headers that indicate your current usage. Wait briefly before testing again. For more details, refer to the Bugsnag API response codes documentation.

Save & Activate the Source

  1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new Bugsnag data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.