How to create and manage API keys

Create a key so another tool can act on your organization, pick its access level, store the secret safely, and revoke it when you are done.

An API key is how you let a tool — a script of yours, a spreadsheet, an assistant like Claude — act inside your organization without anybody typing an email and a password. The key carries exactly the access you granted it: a read-only key can list your events, but it cannot publish, refund or invite anyone.

Think of it as a visitor badge you issue yourself: it lasts as long as you want, it opens only the doors you ticked, and you can cancel it at any moment.

Where the keys live

In the dashboard, click API keys in the sidebar. The page opens with the subtitle "Connect other tools to your Baila account." and the list of existing keys, with the columns Name, Key prefix, Created, Last used, Expiry and Status.

Only people allowed to create and revoke keys see this item in the sidebar. If it is not there for you, ask whoever runs the organization.

Step by step

On API keys, click New key.

Fill in the Key name with something that explains what it is for — "Claude integration", "Sales spreadsheet", "Website script". That name is what will let you decide, six months from now, which key is safe to revoke.

Pick the access level from the role cards. The Read-only card ("Sees everything, changes nothing.") comes preselected — start there and only go higher if the tool genuinely needs to change something. For a different slice, use Need something different? Customize and save it as a new role.

Under Expiry (optional), pick a date if the key is temporary. "Leave blank for a key with no expiry."

Click Create key.

The secret is shown exactly once

As soon as the key is created, a Your key is ready block appears with the warning "Copy it now: for safety, it is never shown again." and the whole key, shaped like baila_live_xxxxxxxx_....

Click Copy — the button turns into Copied!.

Paste the key wherever it will be used (your team's password manager, the tool's secret store, your script's configuration). Never into a chat group or an email.

Click Copied it to dismiss the block.

Baila does not store the key, only a fingerprint of it — which is why it can never be shown again, not even by support. If you close that screen without copying, the only way forward is to revoke the key and create another. What stays visible in the list is just the Key prefix, which identifies the key and opens nothing on its own.

Using the key

The key goes in the Authorization header as a bearer token. For example, to list your organization's events:

curl -H "Authorization: Bearer baila_live_xxxxxxxx_YOUR_KEY_HERE" \
  https://api.vaidebaila.app/api/events

If the key is wrong, expired or revoked, the answer is always the same authentication error, without saying which of the three it was. That is deliberate: spelling out the reason would only help somebody guessing at a key.

The Last used column shows the last time a request arrived with that key. It is the quickest way to find the keys nobody needs any more.

A key can never touch the team or other keys: requests to invite people, change roles or create keys are refused even for a key with broad access. If a key could mint more keys, revoking one would mean nothing.

Connect to Claude / MCP

At the bottom of the keys page there is a Connect to Claude / MCP section. That is where the Server address and the Configuration snippet live — the snippet you paste into your MCP client so an assistant like Claude can answer questions about your events and your sales, with exactly the access this key carries.

The step-by-step is in How to connect Claude to Baila (MCP).

Revoking a key

In the list, every key with the Active status has a Revoke link beside it. Click it and confirm the question "Revoke the key ...? Anything using it loses access immediately."

The key then shows the Revoked status and stays in the list — it does not disappear. Keeping the row is what lets you answer, later, "which key did this, and when did it stop working?". Keys past their expiry date show up as Expired and stop working on their own.

Treat a key the way you treat a password: do not share it, do not commit it to a public repository, and revoke it the moment you suspect it leaked. And always grant the smallest access that does the job — when in doubt, Read-only.