Authentication
When you work with functionalAI from code you handle just two credentials. Each opens exactly one door.
| Credential | Looks like | Opens | Get it from |
|---|---|---|---|
| Personal access token | fnp_… |
The management API (/api/*) — author, evaluate, deploy |
Avatar → API tokens → Mint |
| Function invoke key | fnk_… |
The public runtime (/v1/run/{slug}) for ONE deployed function |
Deploy ▸ API keys |
Signing in to the web app is separate: you’re logged in as yourself and handle no keys at all. This page is about calling the platform from code.
Personal access tokens (fnp_…)
Section titled “Personal access tokens (fnp_…)”A PAT acts as you — it carries your permissions and is scoped to your account.
Use it for the SDK Client, scripts, and CI.
- Shown once at mint. The server keeps only a hash, so nobody (including us) can recover the plaintext later.
- Revoke per token (avatar → API tokens → Revoke); revocation is immediate. A leaked token means revoking one token, not resetting your account.
- Name tokens by what holds them (
laptop,ci-deploy), and mint one per holder rather than sharing. - Sent as
Authorization: Bearer fnp_…— the SDKs do this for you.
Invoke keys (fnk_…)
Section titled “Invoke keys (fnk_…)”An invoke key is deliberately narrow: it calls ONE function’s runtime endpoints
(run, contract) and nothing else. Hand it to the systems that call your
function — a backend service, a webhook consumer — never to people. Same custody
model: shown once, stored hashed, revocable individually.
Which one do I want?
Section titled “Which one do I want?”- Building / evaluating / deploying functions from code → PAT (
Client). - A production system calling a deployed function → invoke key (
Function). - Clicking around the app → just your login; no key handling.
- Provider keys (Anthropic / Bedrock / OpenAI / Gemini) are a separate thing: they’re your model account, added once under API keys and used server-side to run your functions (BYOK). Callers never send them.
Custody rules
Section titled “Custody rules”Never commit a key; pass it via an environment variable. Rotate by mint-new → switch → revoke-old — both stay valid during the overlap. All key material is stored hashed or encrypted server-side and never appears in traces, logs, or error messages.