Bugsnag integration

What it does

The Bugsnag integration lets your agency run a client's error triage from inside TaskJuice. Connect a client's Bugsnag organization once and you can list and filter errors for a project, pull the full stacktrace of an error's latest event, post a comment, reassign or resolve an error, and correlate regressions with releases — feeding any of it into a Slack alert, a ticket, or a client report.

On the inbound side, Bugsnag's Data Forwarding webhook delivers eleven distinct event types, and TaskJuice exposes all eleven as separate triggers — so a workflow can react to a first-time exception without also firing on every repeat occurrence, spike, or comment.

Bugsnag is now sold as SmartBear Insight Hub. The API host and the personal auth token flow described here are unchanged.

Connect a Bugsnag account

1. Open your workspace in TaskJuice and navigate to Connections.
2. Choose Bugsnag and click Connect.
3. In Bugsnag, open My Account Settings → Personal auth tokens and generate a new token.
4. Paste the token into the connection form.

Bugsnag's Data Access API has no OAuth flow — a personal auth token is the only supported credential for third-party integrations. The token carries the full permissions of the user who created it, so create it from an account whose project access matches what the workflows need, and use a separate token per client so revocation stays scoped.

Triggers

All eleven triggers are delivered by a single Bugsnag Data Forwarding webhook. To wire them up: publish the workflow, copy the trigger's ingress URL from the trigger panel, then in Bugsnag open Project settings → Data forwarding → Webhook, paste the URL, and enable the trigger types you want.

• bugsnag/error-created fires the first time a new error is seen in a release stage.
• bugsnag/error-event-received fires on every event matching your filters, including repeat occurrences of a known error.
• bugsnag/error-frequency-threshold fires when an error reaches a configured event or user count inside a time window.
• bugsnag/error-milestone fires when an error hits an occurrence milestone (10, 100, 1000, then every further 1000).
• bugsnag/error-reopened fires when a fixed or snoozed error is automatically reopened. Bugsnag reopens only when the error recurs in a later release — a recurrence on the same app.version it was fixed in is counted, not reopened.
• bugsnag/project-spiking fires when Bugsnag detects an overall spike in matching errors.
• bugsnag/release-created fires when a new release is recorded for the project.
• bugsnag/error-comment-added fires when a collaborator comments on an error.
• bugsnag/error-state-changed fires when a collaborator manually changes an error's state.
• bugsnag/project-sampling-started fires when the project starts being rate-limited and Bugsnag begins sampling.
• bugsnag/project-approaching-rate-limit fires when the project is close to its event rate limit.

Error-level triggers carry an error block; project-level triggers (project-spiking, release-created, project-sampling-started, project-approaching-rate-limit) carry only account, project and trigger, so guard against missing fields when a workflow handles more than one.

Everything about the occurrence lives inside error — error.stackTrace, error.breadcrumbs, error.metaData, error.app, error.device, error.user, error.exceptions, error.occurrences and error.unhandled. There is no separate event block on the wire.

Two ID fields sit side by side and they are not interchangeable:

• trigger.error.errorId is the error ID. Pass this to Get Error, List Events on Error, List Error Comments, Create Error Comment and Update Error Status.
• trigger.error.id is the event ID of the single occurrence that fired the trigger. Passing it to an error action returns 404.

Actions

• bugsnag/list-organizations lists the organizations the connected token can see.
• bugsnag/list-projects lists projects in an organization.
• bugsnag/list-errors lists errors for a project, filtered by status, severity, release stage, or first-seen window.
• bugsnag/get-error fetches a single error by ID, including status, severity, and event and user counts.
• bugsnag/get-latest-event fetches the most recent event on an error — the full stacktrace, breadcrumbs, metadata, and device context.
• bugsnag/list-error-events lists the individual events recorded against an error.
• bugsnag/list-error-comments lists the comments collaborators have posted on an error.
• bugsnag/create-error-comment posts a Markdown comment to an error.
• bugsnag/update-error-comment edits the text of an existing comment.
• bugsnag/delete-error-comment permanently deletes a comment.
• bugsnag/update-error-status opens, fixes, snoozes, ignores, reassigns, discards, or overrides the severity of an error.
• bugsnag/bulk-update-errors applies one triage operation to many errors at once.
• bugsnag/list-collaborators lists the collaborators in an organization, for routing or assignment.
• bugsnag/list-releases lists the releases recorded for a project.
• bugsnag/list-saved-searches lists the saved error searches (filtersets) defined on a project.
• bugsnag/get-saved-search fetches one saved search, including the filter definition it applies.
• bugsnag/get-project-trend fetches the project's error-event trend over time, as buckets for a client report. Supply either Resolution or Bucket count — Bugsnag rejects a call that sets neither. Resolution accepts only 1m, 5m, 30m, 2h and 12h; any other value (1h and 1d included) returns 400.

Organization and project fields are dropdowns backed by live Bugsnag data — pick the client's project by name rather than pasting an ID. Error IDs are normally wired from an upstream Bugsnag trigger.

Known limitations

• Bugsnag rate-limits on a one-minute window and returns 429 with a Retry-After header when the budget is exhausted. TaskJuice surfaces this as a retryable error so downstream resilience policies can back off.
• Bugsnag's Data Forwarding webhook ships unsigned, and its setup form accepts only a target URL — there is no field for a custom header or shared secret. The tenant-scoped ingress URL is therefore the only delivery credential: treat it as a secret and rotate the workflow's ingress URL if it ever leaks. Bugsnag delivers from seven fixed IP addresses, which you can allowlist at the edge for defence in depth.
• The webhook must be configured by hand in the Bugsnag dashboard. Bugsnag does expose a configured-integrations API, but registering a data-forwarding webhook through it takes a create call followed by a separate call per enabled trigger type, which TaskJuice's managed-webhook grammar cannot yet express.
• Requests for resources the token cannot access return 404 rather than 403, so Bugsnag does not disclose whether the resource exists. A surprising "not found" usually means the token lacks project access.
• Deleting an error is deliberately not exposed. bugsnag/update-error-status and bugsnag/bulk-update-errors cover the recoverable triage operations only; permanent deletion stays in the Bugsnag dashboard.
• A saved search cannot be applied to bugsnag/list-errors directly — Bugsnag's error listing ignores a saved_search_id parameter silently rather than rejecting it. Read the search with bugsnag/get-saved-search and map its filters onto the List Errors filter fields instead.
• The webhook's enabled event types cannot be changed through the API at all. PATCH /configured_integrations/:id accepts a trigger_config body and returns 200, then ignores it: switching a disabled type on leaves it active: false, and switching an enabled type off leaves it active: true. The whole map is effectively read-only over the API, so which events a webhook forwards can only be changed in the Bugsnag dashboard. On a default registration that leaves Error Reopened (reopened_config) and Error Occurrence Milestone (power_ten_config) switched off, so those two triggers receive nothing until someone ticks them on under Account menu → Integrations → Data forwarding → (your webhook) → Notify me when. Both were verified end-to-end once enabled.
• Bugsnag ignores unrecognised filter names rather than erroring, so a mistyped filter returns the full unfiltered list rather than failing. The filter fields exposed here are the verified ones (error.status, event.severity, app.release_stage, event.since).