API Keys Settings

API Keys

The API Keys page is where you manage your personal API keys — the secret tokens scripts, integrations, and external tools use to call the Board’s public API on your behalf. Each key inherits your permissions, so anything you can do in the Admin Panel, anything calling with one of your keys can do too.

Open the page from Settings → API Keys (or /settings/api-keys).

Settings — API Keys

API Keys here are per-user, not per-account. They live under your profile, sit alongside your password and 2FA configuration, and are revoked automatically when your user account is deleted. For shop-wide keys managed centrally, see Users → API Keys tab (the admin counterpart on the Users page).

What this page is for
Anatomy of the page
Creating an API key
The one-time reveal modal
Viewing an existing key
Deleting a key
Using a key in an API call
What a key can do
Security model
Tips and best practices

What this page is for

Use this page to:

Issue keys for integrations you set up yourself — a Zapier flow, a custom script, an e-commerce sync, a reporting dashboard.
Track usage — see when each key was last used and prune keys that aren’t.
Rotate — delete an old key and issue a new one when you suspect leak or are handing the integration off.
Audit — see at a glance which tools have access to act as you.

If your team mostly uses one set of integrations, one or two keys per user is plenty. The page is designed to be revisited rarely, not lived in.

Anatomy of the page

A single screen with:

A heading and short description at the top.
A Create API Key button on the right.
A list of Existing API Keys as cards below it (or an empty-state block if you have none).

Each card shows:

Element	What it is
Name	The friendly label you gave the key when creating it.
Masked key	The first 8 and last 4 characters of the key, with `...` in between. Lets you visually identify a key without exposing it on screen.
Created	When you issued the key.
Last used	When the key was last accepted by the API. Never if it’s never been used.
Eye icon	Open the key in a modal so you can view and copy the full value.
Trash icon	Delete the key (with confirmation).

If you have no keys yet, the page shows a key icon and a “No API Keys” empty state instead of cards.

Creating an API key

Click Create API Key in the top-right.
A small dialog opens asking for a Name. Pick something that identifies what uses this key — e.g., “Zapier”, “Production server”, “Inventory sync script”, “Local dev”. The name is for your benefit when scanning the list later.
Click Create.

A new key is generated server-side and shown to you in a follow-up modal. See the one-time reveal modal below.

The key is stored on the server in plaintext (unlike a password, which would be hashed) so it can be displayed again later via the Eye button. This is intentional — see Security model for why.

After Create succeeds, a second modal opens with:

The full key in a copyable code block.
A Copy button next to it (icon switches to a green check briefly when copy succeeds).
An amber warning: “Make sure to copy your API key now.”

Click Copy, paste the key into whatever tool needs it, and close the modal. The new key appears in the list afterwards.

Even though the key is retrievable later via the Eye button (see below), getting it into the integration immediately and confirming it works is the right move — you’ll know in seconds whether you’ve copied correctly.

Viewing an existing key

Lost the key on your end and need to re-fetch it? Click the Eye icon on its card. A modal opens showing the same full key value with a Copy button.

This is a deliberate design choice — keys are recoverable to make day-to-day life easier (re-configuring an integration, sharing with a colleague taking over). The security trade-off is intentional: anyone with your Admin Panel login could already read your keys, so making them visible to you doesn’t expand the attack surface.

If you think a key has actually been compromised (leaked, posted publicly, used from an unfamiliar IP), don’t try to re-view it — delete and create a new one. The old key stops working immediately on delete.

Deleting a key

Click the trash icon on a key’s card. A browser confirmation dialog asks you to confirm.

On confirm:

The key is revoked immediately — any API request using it from this moment on returns 401 Unauthorized.
Any in-flight integration using the key will start failing on its next call.
The key vanishes from your list.

There’s no undo. If you need it back, create a new one and update whatever integration relied on the deleted key.

Using a key in an API call

The Board’s API accepts a key in either of two ways:

An HTTP header: X-API-Key: <your-key>
A query string parameter: ?api_key=<your-key>

The header form is preferred — it doesn’t end up in server logs and URLs as obviously, and it works for all HTTP verbs.

A typical curl call:

curl -H "X-API-Key: pb_abc123..." https://your-board.example.com/api/jobs

The last_used_at timestamp on the key’s card updates after the request succeeds — useful for confirming that a new integration is actually using the right key.

What a key can do

A key inherits the permissions of the user who created it:

An admin user’s key can do anything in the API.
A regular user’s key is constrained by the User Group — modules they can’t see, the key can’t touch.
An employee-role key with limited workstations can only act within those workstation scopes for shop-floor actions.

There is no way to issue a “scoped” or “read-only” key — the system doesn’t currently support sub-user permissions. If you need a more locked-down credential, create a dedicated low-privilege user (with a tight User Group) and create keys under that user.

When you (the user) are deleted, every key you’ve ever created is automatically revoked.

Security model

A few things to be aware of:

Keys are full credentials. Anyone who knows a key can call the API as you. Don’t post one publicly, don’t commit one to a public git repo, don’t share via email or chat.
Plaintext storage on the server. Keys are stored as-is so the Eye button works. This is a deliberate choice that favors recoverability over “even an admin can’t read them” cryptographic hardness. The server-side storage is still per-tenant scoped and inaccessible without database access.
Rotate on staff change. When a colleague takes over an integration, the cleanest move is: they create a new key under their account, swap it in, you delete yours. Avoids any “wait, who created this?” confusion.
Rotate on suspicion. Cheaper than investigating. Delete + recreate takes 30 seconds.
Don’t share one key across multiple integrations. When you need to retire one of them, you can’t selectively revoke. One key per integration = surgical revocation later.

Tips and best practices

Name keys after the tool that uses them. “Zapier-Production” beats “Key 1” — when you scan your list 6 months from now, you’ll thank yourself.
One key per integration. Don’t share a single key between three different tools. When one of them needs to go, you’ll want to revoke just that one.
Check Last Used periodically. A key that hasn’t been used in months either belongs to a dead integration (delete it) or to one that broke silently (investigate).
Use the header form, not the query string. X-API-Key doesn’t end up in server access logs and browser histories.
Delete unused keys. The fewer keys exist, the smaller your exposure if anything ever leaks.
Rotate before risk, not after. Plan a quarterly rotation for high-value integrations. Mark calendars; do it during low-traffic windows.
Don’t issue keys for shop-wide integrations. For tools that should outlive any individual person (a long-running e-commerce sync, an ERP connection), the admin-counterpart Users → API Keys tab is more appropriate — keys can be attached to a dedicated service-account user that doesn’t go away when staff change.
Pair with 2FA on your account. Even if a key leaks, your login is still protected — limiting how an attacker could escalate.