> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inflection.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Two ways to authenticate: a Personal Access Token or an OAuth 2.1 connected app.

Every call is authenticated with a bearer credential in the `Authorization` header:

```
Authorization: Bearer <token>
```

Two kinds of token work. Pick by how your integration runs:

|             | Personal Access Token (PAT)                                   | OAuth 2.1 connected app                                                                 |
| ----------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Best for    | Scripts, internal tools, server-side jobs                     | Multi-user apps, automation platforms, anything that shouldn't hold a long-lived secret |
| Lifetime    | Long-lived, valid until revoked                               | Short-lived access token, renewed with a refresh token                                  |
| Permissions | `READ` / `WRITE` scopes set on the token                      | Acts as the user who authorized the app                                                 |
| Setup       | [Get Your Personal Access Token](/api-reference/get-your-pat) | [Inflection Connected Apps using OAuth 2.1](/agents/connected-apps-oauth)               |

## Personal Access Tokens

PATs look like `inf_pat_…` and carry explicit scopes:

* **`READ`**: required for every `GET`.
* **`WRITE`**: required for `POST`, `PATCH`, and `DELETE`.

## OAuth access tokens

The access token your connected app obtains through the [OAuth 2.1 + PKCE flow](/agents/connected-apps-oauth) works on the Developer API as-is: same header, no separate registration. Two things to know:

* The token **acts as the user who authorized the app**: workspace admins and members can read and write; viewers are read-only.
* The token must belong to a user. Service-to-service tokens are rejected with `403`.

Refresh the access token with your refresh token as usual; nothing else about your API calls changes.

## Auth failures

Auth failures are returned by the gateway with an **empty body**. The status code carries the meaning:

| Status | Meaning                                                                                                                                        |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `401`  | Missing, malformed, or invalid token.                                                                                                          |
| `403`  | Token is valid but lacks the required permission, for example a `READ`-scoped PAT attempting a write or a viewer's OAuth token doing the same. |

<Warning>
  A mistyped path or unsupported method under `/v1` also returns **401** (deny-by-default), not 404. If a valid token is suddenly getting 401s, check the path before the credential.
</Warning>