Account & Billing
API keys
Organization-scoped bearer keys, shown once at creation, everything after that is lifecycle management.
Keys are minted on the API Keys page (developers and org admins), are prefixed sk-prl-infapi-, and authenticate straight against the inference endpoint:
Authorization: Bearer sk-prl-infapi-…The full key is displayed exactly once, at creation, Pearl stores only a digest, so a lost key can't be recovered, only replaced. Afterwards the dashboard shows the key's name, its last characters for identification, its creation date, and its status. Keys don't expire; they live until you retire them.
Revoke vs. delete
| Revoke | Delete | |
|---|---|---|
| Requests using the key | Stop being accepted within a couple of minutes | Stop being accepted; removal is immediate on the next network sync |
| Dashboard listing | Stays visible, badged "Revoked", an audit trail of what was shut off | Disappears from the list |
| Reversible? | No, mint a new key instead | No, and it cannot be undone |
| Usage history | Preserved | Preserved, analytics keep the attribution |
The working rule: revoke to kill traffic, delete to tidy up. Revoke a key the moment it's compromised or retired; delete it later, once you no longer need the line item in the list.
Rotating a key
Rotation is a create-then-revoke, in that order, so there's no gap:
- Create the replacement key and deploy it to your application.
- Verify traffic flows on the new key (watch your app's logs or Analytics).
- Revoke the old key, anything still using it fails loudly within minutes.
- Delete the revoked key once you're confident nothing references it.
Prompt storage
The API Keys page also carries an organization-wide Store prompts switch controlling whether the network retains your prompts and completions. It starts enabled; switch it off and nothing is persisted, full privacy for organizations that want it. Developers and org admins can change it (every member can see it), and like a key change it reaches the network within a couple of minutes. The terms of service spell out the data-handling details.
Practices that pay off
- One key per service and environment ("checkout-prod", "checkout-staging"), names are your only forensic handle, and scoped keys make revocation surgical instead of an outage.
- Keep keys out of code and clients. Environment variables or a secret manager on the server side only, a key in a browser bundle or mobile app is public.
- Leaked key? Revoke it immediately (effective within a couple of minutes), mint a replacement, and review the period's usage in Analytics.
Viewers can see key names and metadata but never key material (nobody can, it isn't stored). Billing admins have no key access at all; see Team & roles for the full matrix.