Management API

Updated 11 October 2026 · BugsRadar team

The management API does from a script what you do in the web app: creates projects and channels, reads and rotates API keys, binds channels to projects and sets rules. It is made for CI pipelines, deploy scripts and Terraform-style setups where every new service gets its own project without a visit to the web app. The API comes with the Business plan.

Token and base URL

In the web app open Settings → Management API and create a token. Name it after what uses it, say CI or Terraform: the name is what the audit log shows for the token's actions. The token is shown once; keep it in the secrets of your CI, never in a repository. Revoking a token stops it at once.

Every request carries the token in the Authorization header and goes to the base URL:

Authorization: Bearer brm_…
https://api.bugsradar.com/api/management/v1/

A token acts as the owner of the account: it sees and changes the owner's own projects and channels. Projects of organizations the owner belongs to as a member are not reachable through it.

Requests and errors

Bodies are JSON, answers are JSON. Ids are GUIDs, dates are UTC in ISO 8601. The HTTP code tells the outcome:

Projects

A project looks like this:

{
  "id": "6f1c…",
  "name": "Payments API",
  "teamId": null,
  "channelIds": ["a2b3…"],
  "rules": [
    { "channelId": "a2b3…", "minLevel": "error", "modules": ["Payments"], "environments": ["Production"] }
  ],
  "allowedIps": ["203.0.113.0/24"],
  "dateUpdated": "2026-10-11T12:00:00"
}

Creating a project from a shell:

curl -fsS -X POST https://api.bugsradar.com/api/management/v1/projects \
  -H "Authorization: Bearer $BUGSRADAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Payments API"}'

API keys

Every project has two keys, primary and secondary; applications report errors with either. Rotate without losing errors: move the applications to the other key, then regenerate the old one.

curl -fsS https://api.bugsradar.com/api/management/v1/projects/$PROJECT_ID/keys \
  -H "Authorization: Bearer $BUGSRADAR_TOKEN"

The keys are secret: put them only into code that runs on your servers. Where a key may go

Channels of a project

curl -fsS -X PUT https://api.bugsradar.com/api/management/v1/projects/$PROJECT_ID/channels \
  -H "Authorization: Bearer $BUGSRADAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channelIds": ["a2b3…", "c4d5…"]}'

Rules

A rule is a filter on one channel of one project: the channel gets an error only when it fits every condition. A condition you leave out fits any error. How rules work

Channels

The body of POST /channels names the service in type and carries its credentials in the object of the same name. Credentials cannot be changed later: other credentials are another channel.

curl -fsS -X POST https://api.bugsradar.com/api/management/v1/channels \
  -H "Authorization: Bearer $BUGSRADAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type": "slack", "name": "#payments-alerts", "slack": {"webhookUrl": "https://hooks.slack.com/services/…"}}'

Where the credentials come from for each service: channel setup guides.

Limits and the audit log

The plan's limits apply as in the web app: the Business plan has no limits on projects and channels; an account that has more than its plan includes cannot add anything new until the extras are removed. Up to 20 tokens per account. Everything a token does is written to the audit log of the organization under the token's name, with the address the request came from.