Access Tokens

What is an Access Token?

Access tokens are essential for enabling various data interactions within your Rollbar projects. Each project has its own unique set of access tokens, making them indispensable for routing data through different SDKs. If you're setting up the Rollbar MCP Server in Claude, Cursor, or VS Code, you need an access token with read scope. A project access token connects the server to one project. An account access token lets it work across every project in your account. Add write scope if you want your assistant to update items.

Types of Tokens

Service tokens and personal access tokens are both account access tokens. Most API endpoints that accept an account access token accept either kind. A few, such as creating an item comment, accept only a personal access token.

How Rollbar protects your access tokens

Rollbar stores a hash of your token, not the token itself. New tokens are stored as a SHA-512 hash. Rollbar can check a token you send against that hash, but nobody, including Rollbar, can read the token back out of it. That's why you see the full token only once, when you create it. After that, the token page shows a public ID, which identifies the token but can't be used to call the API or send data.

The tokens you ship in your app can only send data. A new project token with the post_server_item or post_client_item scope can't also have read or write. A token embedded in a web page or a mobile app can report errors, but it can't read your data or change your project.

A personal access token can't reach more than its user can. It carries its user's permissions and stops working when the user is removed from the account, is deleted, or is locked out. Account owners can administer the personal access tokens of every user in the account, including revoking them.

You can shut a token off right away. Disabling a token makes Rollbar reject it with a 403 until you turn it back on. Expiring a token shuts it off for good. Regenerating issues a new token with the same settings and retires the old one.

Rate limits cap what a leaked token can send. Every token is held to Rollbar's system limit, and on paid plans you can set a lower limit per token. See Rate Limiting below.

If a token is exposed, regenerate it and put the new token in your apps. The old token stops working as soon as you regenerate.

Project Access Scopes

You can find and administer your project access tokens in Project -> Settings -> Project Access Tokens. Project access tokens can have any or all of the following scopes:

New projects are created with four tokens, one with each scope. As client tokens often need to be embedded in publicly visible code (i.e. the HTML source of a page)

📘

A good practice is to use a separate client-side token with post_client_item scope, which only permits event sending from client-side platforms.

Account Access Tokens

Use an account access token when a script or tool needs to work with the account itself, or with more than one project. Creating projects, managing users and teams, and querying across all your projects all need an account access token, because a project access token can only reach its own project.

Account access tokens can have these scopes:

Account access tokens don't have the post_server_item or post_client_item scopes. To send errors and deploys from your app, use a project access token.

When an endpoint works on a single project, an account access token tells Rollbar which project to use with a project_id parameter. If that project doesn't exist or belongs to another account, Rollbar returns a 404 when project_id is part of the URL and a 403 with the message Requires project access everywhere else.

Service Tokens

A service token reaches every project in your account and doesn't belong to any user, so it keeps working when people join or leave your team. That makes it the right choice for automation such as provisioning scripts and CI jobs. Account owners create service tokens on the Service tab of Settings → API access tokens.

Personal Access Tokens

A personal access token acts as you. A request made with it succeeds only when you could do the same thing yourself in Rollbar. It reaches only the projects your teams have access to, and it only lets you do what your teams' access levels allow.

Use a personal access token when:

• The action should be credited to you. Comments you create through the API are attributed to you and show up in the item's timeline marked as coming from the API. Creating a comment requires a personal access token with write scope, and Rollbar rejects project access tokens and service tokens on that endpoint. See the Item Comments guide.
• You want API access without a token that reaches the whole account. A personal access token is a good fit for your own scripts and tools, because it can never reach more than you can.
• You want access to end when a person leaves. A personal access token stops working when its user is removed from the account, is deleted, or is locked out of Rollbar.

Personal access tokens have the same read and write scopes as service tokens.

Creating and managing personal access tokens. Each user creates their own on the Personal access tokens page in User Settings. Account owners can administer the personal access tokens of every user in the account on the Personal tab of Settings → API access tokens.

What your teams' access levels allow. When a personal access token can't do something, Rollbar returns a 403 that names the missing permission, such as Requires config permission. You get each permission from your teams' access level:

Everyone in your account belongs to the Everyone team, which counts as Standard access. So every member can view the account's users, teams, and invitations, and has config on each project the Everyone team can access.

If a request names a project none of your teams can access, Rollbar returns a 403 with the message Requires project access. Some list endpoints, such as GET /api/1/projects, return only what you can see. Others return a 403 unless you can see the whole list, and each endpoint's API reference entry says which.

Editing and Configuring Tokens

Managing individual tokens is straightforward, and now we've added the ability to edit multiple tokens in bulk for convenience. You'll find various actions that can be performed for each token and options for bulk editing.

Individual Token Actions

Here's a brief rundown of the actions you can perform on each token:

Bulk Editing

Bulk editing is a useful feature for managing multiple tokens at once. Select the checkboxes next to the tokens you want to edit to utilize this function. Once selected, an action menu will appear in the table's header, displaying available actions. It's worth noting that the collective status of the tokens selected will determine the options presented. For example, if you choose an 'Active' and an 'Expired' token, the 'Disable' action won't be available since expired tokens can't be disabled. However, actions like 'Delete' and 'Regenerate' will remain accessible since active and expired tokens can undergo these changes.

This new approach streamlines your token management process, making it easier to enact large-scale changes or quickly adjust to new requirements.

Rate Limiting

🚧

Rate Limit is only available for Paid Accounts

What is a Rate Limiting?

Rate limiting is the mechanism that restricts the amount of data an access token can send to Rollbar within a specific time window. You can learn more by visiting our rate limiting documentation

System-Defined Rate Limiting

Rollbar imposes a system-defined rate limit of 50,000 API requests per 1 minute, which acts as the upper boundary for data intake.

User-Defined Rate Limiting

For paid users, you can set your rate limits up to the 50,000 API requests per 1-minute system limit. These can be customized for various time frames, including 1 minute, 5 minutes, 30 minutes, 1 hour, 1 day, 1 week, and 30 days.

Token Status

Understanding the status of your access tokens is crucial for effective project management and security. On the project access token page, you'll notice a 'Status' column color-coded to represent the current state of each token. We've introduced five key statuses to guide you:

Active

Active tokens are fully operational and can be employed for all authorized data interactions based on their scopes.

Disabled

If a token is compromised or being misused, it can be disabled. Once disabled, Rollbar will no longer accept data sent via this token and will return a 403 response code. You can disable a token via the context menu at the end of the token's row in the table or by bulk-selecting multiple tokens. Disabled tokens can be re-enabled at any time.

Expiring Soon

A token with an 'Expiring Soon' status is still fully operational, just like an 'Active' token, but has an expiration date within one month. When the expiration date is reached, the token will get an 'Expired' status and become inoperable.

You cannot set token expiration dates; it is an internal Rollbar feature used in particular circumstances.

Expired

Tokens with an 'Expired' status are inoperable and cannot be reactivated or modified. They are retained in your project records primarily for historical reference. Expired tokens can also be easily regenerated if necessary, retaining their original configurations, such as scope and rate limits.

This feature offers a convenient way to manage your tokens effectively and avoid any potential issues that may arise during your project.