API keys

Your apps and servers prove who they are with an API key. Each key belongs to one environment.

Key	Looks like	Use it in
Publishable	`pb_pk_…`	Browsers and mobile apps. Safe to ship. It can only do what your access rules allow the public or a signed-in user to do.
Secret	`pb_sk_…`	Your servers only. It can manage the environment, so never put it in a browser, app or repository.

Create a key

Settings → API keys → New API key.
Choose a Name (what it’s for, such as Web app or Nightly job) and the Key type.
Under Permissions, choose what it may do. Start from a preset, then adjust. Areas that manage the environment need a secret key.
Optionally set Limits:

Limit	Effect
Expires	The key stops working on that date.
Allowed IP ranges	Every other address is refused. Comma-separated IPs or CIDR ranges such as `203.0.113.0/24`.
Allowed routes	Anything outside these is refused at the gateway, whichever route it uses. Examples: `GET /rest/v1/`, `POST /flows/v1/`.

Create. The key is shown once. Copy it now and store it as a secret in your host.

Rotate when someone who knew a key leaves, or on a schedule.

Open the key and choose Rotate key.
Choose Keep the old key working for how long, so your apps have time to switch.
Copy the replacement (it has the same permissions and limits).
Deploy it, and the old key expires when you said.

Revoke key stops anything using it at once. This cannot be undone. Make a new one if you need it.

Each key shows when it was last used and how many times. Every request carries the key’s name in Activity, so you can find which key did what.

One key per app or job, so you can revoke one without breaking the rest.
Give each the least it needs. A job that reads one table shouldn’t hold a key that can manage the environment.
Use Allowed IP ranges for servers with fixed addresses.
Keep secret keys in your host’s secret store, never in code.
Use machine identities for services that call your API as themselves.