---
title: Authentication
description: Authenticate to the Honeybadger API v3 with a user or account API token, and check what a token can reach.
url: https://docs.honeybadger.io/api/v3/authentication/
---

API v3 is in preview

Endpoints and response shapes [can change before general availability](https://docs.honeybadger.io/api/v3/#preview). API v2 is unchanged.

API v3 takes a token, sent as a Bearer token. There are three kinds:

| Token | Prefix | Acts as | Create it in |
| - | - | - | - |
| User API token | `hbu_` | You | [User settings](https://docs.honeybadger.io/guides/user-settings/#api-tokens) |
| Account API token | `hba_` | Your account | [Account settings](https://docs.honeybadger.io/guides/accounts/#api-tokens) |
| OAuth access token | `hbo_` | You, through an app | Not created by hand. Issued when you authorize an app, such as the [Honeybadger MCP server](https://docs.honeybadger.io/resources/mcp/). |

API tokens are opt-in while API v3 is in preview. To turn them on for your account, email <support@honeybadger.io>.

Your API v2 personal auth token doesn’t work with API v3.

## Sending a token

Send the token in the `Authorization` header. The examples in this reference read it from the `HONEYBADGER_API_TOKEN` environment variable:

```sh
export HONEYBADGER_API_TOKEN=hbu_your_token


curl https://app.honeybadger.io/v3/projects \
  -H "Authorization: Bearer $HONEYBADGER_API_TOKEN"
```

## Choosing a token

Use a **user API token** for scripts and tools that act as you. It reaches only the projects you can reach, and when you lose access to a project, the token loses it too.

Use an **account API token** for CI, deploy scripts, and other automation that shouldn’t depend on one person’s access.

To manage account members, team members, or invitations, use a user API token or an OAuth token with the `write` grant. Account API tokens can’t have the `account:write` scope. With `team:write`, they can manage teams but not team members or invitations.

## Scopes

Each token carries scopes, which grant access to one resource each, such as `faults:read`, `faults:write`, and `projects:create`. Each scope is checked on its own: `faults:write` doesn’t include `faults:read`, so a token holding only `faults:write` can’t list or fetch faults. Every operation in this reference lists the scopes it requires.

An OAuth token’s scopes depend on its grant, `read` or `write`. Each grant is a fixed list of scopes. Neither includes `incidents:read` or `incidents:write`, so status page incidents need an API token.

A token can also be limited to specific projects, and can have an expiration date.

## Checking a token

[`GET /v3/token`](https://docs.honeybadger.io/api/v3/tokens/get-token/) reports what the token making the request is: its kind, scopes, the account it belongs to, the projects it can reach, and when it expires. It needs no scope, so any token can call it, including one with no scopes at all.

```sh
curl https://app.honeybadger.io/v3/token \
  -H "Authorization: Bearer $HONEYBADGER_API_TOKEN"
```

## API tokens and ingestion keys

API tokens call API v3. An ingestion key is what your app uses to report errors, events, and other data to Honeybadger, and it can’t call API v3. The web UI and the rest of these docs call it your project’s [API key](https://docs.honeybadger.io/guides/projects/#api-keys). API v3 manages ingestion keys with the [Ingestion keys](https://docs.honeybadger.io/api/v3/ingestion-keys/list-ingestion-keys/) operations.

---

## Try Honeybadger for FREE

Intelligent logging, error tracking, and Just Enough APM™ in one dev-friendly platform. Find and fix problems before users notice.

[Start free trial](https://app.honeybadger.io/users/sign_up)

[See plans and pricing](https://www.honeybadger.io/plans/)