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: whatever databases your account can reach, a request wearing your key can reach too. That is exactly why the rest of this page is mostly about handling it well.

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"}}

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 the key is your whole account, not one table.

Tabla has one door: the same API serves the screen and every external caller, and there are no scoped or read-only keys today. 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 row 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.