Rollbar integration

What it does

The Rollbar integration lets your agency send occurrences into a client's Rollbar project, query and triage items across environments, mutate item status from inside a workflow, and record deploys so subsequent errors correlate against the new code version. Connect a client's project access token once and your workflows can ingest errors, list and inspect items, resolve or mute items, report and list deploys, and react in real time when Rollbar surfaces a new item or reactivates a previously resolved one.

Connect a Rollbar account

1. Open your workspace in TaskJuice and navigate to Connections.
2. Choose Rollbar and click Connect.
3. In a new tab, sign in to rollbar.com as the client and open the project you want to integrate.
4. Open Project Settings, then Access Tokens, and copy a token that includes the scopes your workflows need (post_server_item for ingestion, read for queries, write for status mutations).
5. Paste the token into TaskJuice and save the connection.

To rotate or revoke the token later, return to the project's Access Tokens screen in Rollbar, regenerate the token, and update the TaskJuice connection. Use a separate token per client project so revocation stays scoped.

Triggers

• rollbar/new-item fires the first time Rollbar sees a new distinct error item in the project, with the item id, environment, level, framework, and first occurrence payload.
• rollbar/reactivated-item fires when a previously resolved item reoccurs and Rollbar reactivates it, carrying the item id, environment, current status, and the reactivating occurrence.

Each webhook delivers one event per POST. Configure the webhook in the Rollbar UI with a shared secret carried in the X-Rollbar-Signature header; TaskJuice verifies the header on every inbound POST and rejects unsigned traffic.

Actions

• rollbar/track-occurrence posts a single occurrence to /api/1/item/ with environment, level, message body, code version, custom context, and an optional person object.
• rollbar/list-items pages through items in the connected project with filters for status, level, environment, framework, and assignee.
• rollbar/get-item fetches one item by its numeric id, including counter, level, status, and aggregate occurrence counts.
• rollbar/update-item-status mutates an item via PATCH /api/1/item/{id}/ to resolve, mute, archive, or reassign it, and optionally records the version that resolved it.
• rollbar/report-deploy records a deploy against an environment and revision so subsequent occurrences correlate against the new code version.
• rollbar/list-deploys pages through recent deploys for the connected project, returning revision, environment, status, and timestamps.

Known limitations

• The integration calls the Rollbar v1 REST API with a single project access token. Per-token rate limits and scope grants (post_server_item, read, write) are governed by the client's Rollbar account, not by TaskJuice. When Rollbar returns a 422 with a validation error, TaskJuice surfaces it as a non-retryable validation failure; 429 responses are surfaced as retryable rate limits.
• A project access token scopes to one Rollbar project. Connect each client project separately so revocation, environments, and deploy history stay isolated.
• Rollbar does not sign webhook payloads with HMAC. Inbound authentication relies on a static shared secret carried in the X-Rollbar-Signature header. Treat the secret like an API key, store it in TaskJuice, and rotate it in Rollbar when staff rotate.
• The status mutation action requires a token with the write scope. Tokens scoped to read or post_server_item only will receive a 403 from Rollbar, which TaskJuice surfaces as a non-retryable FORBIDDEN failure.