# Baserow Database Tokens: Creating and Scoping API Access

> Generate a permanent Baserow credential for scripts and integrations - create, update, delete, and read rights apply per workspace, revocable anytime.

Source: https://opennix.org/en/docs/baserow/webhook-api/personal-api-tokens/


A database token is a permanent credential for Baserow's REST API - it stands in for a username and password inside scripts, external applications, and automations, and its permissions can be limited to one workspace and one set of operations: create, read, update, or delete rows.

## Overview

Unlike a session, which ends when a user logs out, a database token stays valid until someone revokes it. That makes it the standard way to connect an external script, backend service, or integration that needs to read and write table data over the REST API without a person present at every request. A token is scoped to a single workspace and only touches row data - it cannot create, edit, or delete the table structure itself (fields, views) through the database token.

## Database Token vs. JWT Token

Open-source Baserow supports two authentication methods, and each serves a different purpose:

| Method | Lifetime | Typical use | Access scope |
|---|---|---|---|
| Database token | Permanent, until revoked | External apps, automations, long-running scripts | Row data only |
| JWT token | About 7 minutes | Development, short test requests | Full account access |

The key distinction: a database token only lets you read or manipulate the data inside a table's rows. To create, update, or delete the table's own structure - fields, views, the table itself - a JWT token obtained through a normal account login is required instead.

## Token Permissions

Every token can carry up to four independent permissions:

| Permission | What it allows | Typical API endpoint |
|---|---|---|
| Create | Add new rows (includes read access) | `POST /api/database/rows/table/{table_id}/` |
| Read | View existing data | `GET` on row endpoints |
| Update | Modify existing rows (includes read access) | `PATCH` on row endpoints |
| Delete | Remove rows | `DELETE` on row endpoints |

Permissions are assigned at the workspace level, but a token can also be scoped to specific databases or tables inside it - once scoped, it cannot reach the rest of that workspace's data.

## Creating a Database Token

1. Open your account settings and go to the **Database tokens** tab.
2. Click **Create token +**, give the token a descriptive name, and pick the workspace it belongs to.
3. Restrict its scope to specific databases or leave it with full access to every database in the workspace, then set the create, read, update, and delete permissions.
4. Generate the token, copy its value immediately, and store it somewhere secure - the dialog will not show the full value again once it closes.

![Baserow database token creation dialog with workspace and permission selection](/images/baserow/webhook-api/personal-api-tokens-create.jpg)

## Managing Existing Tokens

The `⋮` menu next to a token's name exposes the following actions:

- **Copy** - copy the token's value through the copy icon without generating a new one.
- **Regenerate** - issue a fresh value for the same permission set; the old value stops working immediately, which is the right move if the token may have leaked.
- **Rename** - change a token's label without affecting its permissions or how it functions.
- **Delete** - revoke a token entirely once it is no longer needed.

![Baserow database token management menu: copy, regenerate, rename, and delete](/images/baserow/webhook-api/personal-api-tokens-regenerate.jpg)

## Using a Token in API Requests

Pass the token's value in the `Authorization` header of every REST API request:

```
Authorization: Token YOUR_DATABASE_TOKEN_HERE
```

Example request that reads a table's rows:

```
curl -H "Authorization: Token YOUR_DATABASE_TOKEN_HERE" \
     -H "Content-Type: application/json" \
     https://your-baserow-domain/api/database/rows/table/{table_id}/
```

Find the `{table_id}` value in Baserow's address bar or through the API documentation, as described in [Database and Table ID](/docs/baserow/webhook-api/database-and-table-id/). For the complete list of endpoints, response formats, and request examples in several languages, see [Baserow REST API](/docs/baserow/webhook-api/database-api/).

## What to Know Before Creating a Token

- A token belongs to a single workspace - working across several workspaces means creating a separate token for each one.
- Once the creation dialog closes, the full token value is never displayed again - regenerating is the only way to get a fresh value if the original is lost.
- Self-hosted deployments of open-source Baserow have no built-in limit on API request frequency by default, unlike Baserow's hosted cloud service, which caps concurrent requests.
- If the goal is reacting to data changes the moment they happen rather than polling the API on a schedule, [webhooks](/docs/baserow/webhook-api/webhooks/) are a better fit than a token-based polling loop.

## Frequently Asked Questions

**How is a database token different from a normal account login?** Logging in issues a short-lived JWT token with full access to everything in the interface, including changes to table structure. A database token is permanent but limited strictly to row-level operations - create, read, update, or delete.

**Can one token work across several databases?** Yes, as long as its scope was not narrowed to a single database at creation time - an unscoped token can reach every database in its workspace within the create, read, update, and delete permissions it was granted.

**What should happen if a token is compromised?** Open the token's menu and regenerate it right away - the old value stops working instantly, and the new value needs to be saved and updated everywhere the previous token was in use.

**Is a database token required to set up a webhook?** No, webhooks are configured separately through the database interface and do not need a token to deliver notifications - a token becomes necessary when an external application itself needs to pull data from Baserow or write changes back to it.

Next, read [Baserow REST API](/docs/baserow/webhook-api/database-api/) for the full list of endpoints for reading and writing table data.