# API tokens


> Create a token to use the API, the CLI, or the MCP server, and where to find it afterwards. You cannot: it is shown once.
Everything the dashboard does is available through the API, and a token is how you authenticate to it. The CLI and the MCP server use the same token.

## Creating one

Go to **Settings** in the main navigation, which is your **workspace settings**, then the **Security** tab, then **Tokens**. Choose **Show**, name the token, and choose **Add**.

There is a Security tab in your account settings too, and it is the wrong one: that holds passkeys and two-factor rather than tokens. See [Where settings live](/docs/get-started/reference/where-settings-live/).

> [!IMPORTANT]
> Copy it now and store it somewhere safe. It is displayed once and never shown again. If you lose it, delete it and create another.

Name tokens after where they are used rather than who made them. `ci-pipeline` tells you what breaks when you revoke it; `alex-token` does not.

## What a token is bound to

A token belongs to **one member in one workspace**. Both, not either.

Creating one in a workspace stamps it with your identity and that workspace. It cannot reach a different workspace, and it cannot act as anybody else.

So if you work in three workspaces and want to script all three, that is three tokens.

## What scope it has

Exactly what **you** can do in **that workspace**, and nothing more. A token carries your role, so:

| Your role | What the token can do |
| --- | --- |
| User | Screens, content, playlists, apps |
| Billing Manager | The same, plus billing |
| Admin | The same, plus members and workspace settings |
| Owner | Everything, including creating Admins |

There is no narrower scope to select. You cannot make a read-only token, or one limited to content, and there is no expiry date to set.

That absence is the thing to design around.

> [!IMPORTANT]
> If a script only needs to upload content, the safe move is a token from an account that only has permission to upload content. Create a User account for the automation and make the token from that, rather than handing a pipeline an Owner's token because an Owner happened to set it up.

An [MCP](/docs/developers/mcp/) assistant is the same question with more urgency, because it acts on instructions written in English. See [Permissions](/docs/developers/mcp/overview/permissions/).

## When a member leaves or is disabled

A token is only as alive as the membership behind it.

| What happens to the member | What happens to their tokens |
| --- | --- |
| Disabled in the workspace | Stop returning data |
| Removed from the workspace | Stop returning data |
| Role reduced | Lose whatever that role lost |
| Leaves the company, still a member | Nothing |

The membership check runs on every request rather than at sign-in, so there is no window where an old token keeps working after access is withdrawn. A role change lands the same way, because the token carries the role rather than a copy of it: demote an Admin to User and their pipeline loses member management the moment you save.

The last row is the one that bites. Somebody leaving without being removed looks like offboarding was done, and their tokens carry on working exactly as before.

### Plan for it before it happens

The tokens list shows each token's name and when it was created, and lets you delete one. It does not show who created a token, so tokens are not something you can audit across a workspace from the dashboard.

That has a practical consequence: **removing or disabling the member is the reliable lever** during offboarding, and it is the one you should use. It also breaks anything those tokens were running, silently, which is usually a CI pipeline nobody remembers.

Two habits make that a non-event.

**Do not let automation depend on a person.** A token named `alex-token` is a resignation away from an outage. Create automation tokens from an account that exists for the job, so offboarding a human never touches them.

**Keep a record outside Screenly** of which token runs what, and who made it. A name like `ci-deploy-prod` tells you what breaks when it stops working; it does not tell you whose membership it depends on.

## Revoking one

Delete it from the same page. It stops working immediately, and anything using it starts getting `401` rather than failing quietly.

Rotate on the usual triggers: somebody leaves, a token turns up somewhere it should not, or a pipeline is retired.

See [the API](/docs/developers/api/), [the CLI](/docs/developers/cli/), and [the MCP server](/docs/developers/mcp/) for what to do with it.