---
title: API Tokens
description: Generate scoped API tokens for CI/CD pipelines, scripts, and automation workflows with granular permission control.
---

<Note>
  API Tokens require a Sencho **Team Pro** license. Personal Pro and Community Edition do not include this feature.
</Note>

API tokens let you authenticate external tools - CI/CD pipelines, deployment scripts, monitoring integrations - without sharing user credentials. Each token is scoped to a specific permission level so you can follow the principle of least privilege.

## Permission scopes

Every token is created with one of three permission levels:

| Scope | Allowed actions |
|-------|----------------|
| **Read Only** | `GET` requests only - view stacks, containers, metrics, and settings |
| **Deploy Only** | Everything in Read Only, plus stack operations: deploy, down, restart, stop, start, update |
| **Full Admin** | Full stack and container management - all read and write operations on stacks, containers, images, and system metrics |

Choose the narrowest scope that fits your use case. A CI pipeline that only deploys stacks should use **Deploy Only**, not Full Admin.

### Universal restrictions

Regardless of scope, **all** API tokens are blocked from:

| Category | Description |
|----------|-------------|
| **Password management** | Changing user passwords |
| **User management** | Creating, updating, deleting, or listing user accounts |
| **SSO configuration** | Viewing, creating, updating, deleting, or testing SSO providers |
| **Node management** | Adding, updating, or deleting remote nodes |
| **License management** | Activating or deactivating license keys |
| **Token management** | Creating, listing, or revoking API tokens |
| **Console access** | Generating console session tokens for interactive terminals |

These restrictions ensure that API tokens cannot escalate privileges or modify the identity and infrastructure configuration of your Sencho instance. These operations require a human user session (browser login).

## Creating a token

1. Open **Settings Hub** and navigate to the **API Tokens** tab (visible to Team Pro admins only).
2. Click **Create Token**.
3. Enter a descriptive name (e.g., "GitHub Actions deploy"), select a permission scope, and optionally choose an expiration period (30, 60, 90 days, or 1 year). Tokens without an expiration must be revoked manually.
4. Click **Create**. The raw token is displayed **once** - copy it immediately.

<Frame>
  <img src="/images/api-tokens/api-tokens-overview.png" alt="API Tokens management view in Settings Hub" />
</Frame>

<Warning>
  The token value is shown only at creation time. Sencho stores a SHA-256 hash of the token, not the token itself. If you lose it, revoke and create a new one.
</Warning>

## Using a token

Pass the token as a Bearer token in the `Authorization` header:

<CodeGroup>
```bash curl
curl -H "Authorization: Bearer YOUR_TOKEN" \
     https://your-sencho-instance/api/stacks
```

```yaml GitHub Actions
- name: Deploy stack
  run: |
    curl -X POST \
      -H "Authorization: Bearer ${{ secrets.SENCHO_TOKEN }}" \
      https://your-sencho-instance/api/stacks/my-app/deploy
```
</CodeGroup>

### Scope enforcement

If a token attempts an action outside its scope, Sencho returns a `403` response with a `SCOPE_DENIED` error code:

```json
{
  "error": "API token scope \"read-only\" only allows GET requests.",
  "code": "SCOPE_DENIED"
}
```

## Revoking a token

Click the trash icon next to any token in the API Tokens settings tab. Revocation is immediate - any in-flight or future requests using the revoked token will receive a `401` response.

## Security model

- **Hashed storage** - Only a SHA-256 hash of the token is stored in the database. The raw token is never persisted.
- **Audit trail** - All actions performed via API tokens are recorded in the [Audit Log](/features/audit-log) under the creating user's username.
- **Optional expiry** - Tokens can be created with an expiration period (30 days, 60 days, 90 days, or 1 year). Tokens without an expiry must be revoked manually when no longer needed.
- **Scope enforcement** - Permission checks happen at the middleware level before any route handler executes, ensuring consistent enforcement across all endpoints.
