API keys: the shape, the naming, the revoking

An API key is the credential anything non-human carries into Tabla — a Make scenario, a cron script, your own server. It authenticates as you, and you choose how much of your account it carries: every database or a named few, read-and-write or read-only. Whatever you choose narrows what the key can do and never widens it — a key can never reach past your own roles.

The shape

Authorization: Bearer key_xxxx.your-secret

The value has two halves joined by a dot. Before the dot is the key's id — key_ plus twelve characters, the public half, the one your key list shows. After the dot is the secret. Tabla stores only a hash of it, so it is shown exactly once, at creation, and can never be shown again — a lost secret means revoking the key and minting a new one. The same reveal-once pattern as a webhook's signing secret.

To check which key a request is actually using:

curl "https://tabladb.com/api/meta/whoami" \
  -H "Authorization: Bearer key_xxxx.your-secret"

{"user": {"id": "usr_bg44ivm89xzw", "email": "laila@sakkaraplants.com",
  "name": "Laila Hassan"},
 "key": {"id": "key_xxxx", "name": "Guides demo seeder",
  "created_at": "2026-08-09T22:11:11.993Z",
  "last_used_at": "2026-08-09T22:59:38.673Z",
  "access": "read_write", "databases": "all"}}

databases is either "all" or the exact list the key was narrowed to. This is the call to make when an integration starts refusing and nobody remembers what the key was set to.

Choosing what a key reaches

Both choices sit under the name box, already answered with All databases and Read and write — so if you don't care, type a name and press Create as before. If you do:

• Read only refuses every write, whatever your own role is. It is the setting for a dashboard, a reporting script, a nightly export, or an AI agent you would rather could not delete a record. A write attempt answers 403 with This API key is read-only.
• All databases includes the ones you make later, so a key doesn't silently stop covering next month's work. Narrowing to a named few is the other option; anything outside answers 404, exactly as another account's database does. A key can't confirm that something it can't reach exists. A narrowed key also can't create a database — a new one would be born outside its own list — so a script that makes databases keeps All databases.

The Choose databases option only appears once you have more than one database — with one, there is nothing to choose between.

Both settings are editable afterwards. Click the grey summary line under a key's name, change it, Save. The secret doesn't change, so nothing needs re-pasting into Make or your server — which is the point: narrowing a key you've become uneasy about should take seconds, not a redeployment.

Whatever a key's settings, two acts stay a person's job, from the app: deleting a database, and making someone an owner. Both are permanent in a way revoking a key can't undo. Everything else the API offers, a read-and-write key can do — including deleting records and tables, which the trash holds for seven days.

One key per integration

Keys are minted in the account menu (your avatar, top right) under API keys…. The name box suggests it itself: "Name this key, e.g. Zapier". Take the hint literally — one key per caller:

• Revoking one integration doesn't break the others.
• The list shows each key's last used date, so a key that stopped being used, or one being used when it shouldn't be, stands out by name.
• When a request misbehaves in your logs, the key id in its header tells you which system sent it.

Where a key must never go

Not in browser code. Not in a mobile or desktop app you ship. Not in a public repository. Anywhere a user can open devtools or unzip your bundle, they can read the key — and even a read-only key narrowed to one database reads everything in it.

Tabla has one door: the same API serves the screen and every external caller. So the architecture that works is: browsers talk to your server, and your server talks to Tabla, holding the key where nobody can view-source it. If what you actually want is to show people a table without writing any server, that is what public view links are for — they carry no key at all.

Revoking

In the same API keys… dialog, the trash icon next to a key, then Revoke key. The confirmation says what happens, plainly: the key stops authenticating immediately, and anything still using it starts failing. There is no grace period — the key is deleted, and the very next request wearing it gets:

{"error": {"code": "unauthorized",
  "message": "Missing or invalid API key. Expected: Bearer <id>.<secret>."}}

That is a feature. The moment a key leaks into a paste or a repo, revoking it is one click and takes effect now.

600 requests a minute

Each key gets 600 requests per minute, counted in a sliding window and charged only after the secret is verified — someone hammering your key id with wrong secrets cannot spend your budget. Request 601 inside the window answers:

HTTP/1.1 429 Too Many Requests
retry-after: 3

{"error":{"code":"rate_limited","message":"Too many requests. Retry in about 3s."}}

That response was produced the honest way — 600 real requests, then one more. Retry-After is whole seconds until the oldest counted request ages out of the window; sleep that long and retry, and the retry succeeds. Two keys are two budgets, which is one more reason each integration should carry its own. The other caps live in errors and limits.

Start to finish with a fresh key in the API in five minutes; the full reference is at /docs/api.