Developers
Isolation & keys
How Frontpage fences sites, scopes API keys, and prevents cross-tenant access from the CLI.
Site targeting
Every site-scoped API call requires a subdomain slug (example: asimov-press).
The platform binds work to branch site/<slug>. Clients cannot pass a branch, ref, repo, or
clone URL.
- Accepted:
frontpage use asimov-press,--site asimov-press - Rejected:
asimov-press.frontpage.host,www.example.com, full URLs
API keys
- Minted in the editor (Developers). Prefix
fp_live_. - Stored hashed server-side; the secret is shown once.
- Account-wide: not limited to a single site. The key acts as the minting user on every site they can access.
- Bearer tokens cannot mint keys. Session owners who own at least one live site can mint.
Sharing a key shares that user’s power. There is no “editor-limited” key in v1. Rotate (delete) keys from the Developers panel if leaked.
Authorization outcomes
| Situation | HTTP | CLI exit |
|---|---|---|
| Missing / invalid key | 401 | 4 |
| Member but under-privileged for the action | 403 | 4 |
| Not a member of the site (existence hidden) | 404 | 4 |
| API feature disabled for the environment | 404 “not found” | 5 (message mentions PUBLIC_CLI_ENABLED) |
Important for agents: exit 4 on a 404 often means “no access / not found,” not only a bad password.
What is never returned
- GitHub tokens
- Clone / remote URLs
- Other tenants’ branches or file trees
- Module OAuth secrets and raw secret values (masks only)
Platform-admin note
API-key authorization does not use platform-admin fleet override. Keys cannot godmode across the fleet.