API keys, and letting an agent into the house
A key belongs to the house, not to a seat, so removing a person cannot orphan a running integration. Two roles, neither of which reaches money, and revocation that takes effect on the next request.
A key belongs to the house, not to the person who minted it. Take that person off the team and the nightly packshot pipeline keeps running. That is the whole reason keys are not per-seat.
For how to mint and call, read the API. This page answers what goes wrong.
"I lost the key"
Mint a new one and revoke the old one. The secret is returned once, at creation, and only its hash is stored — there is no route, no screen and no support request that can recover it. That is the property that makes a leaked database not a leaked key.
"I revoked a key and it still works"
It does not. Revocation is read from the row on every single call, so it takes effect on the very next request. There is no cache to wait out.
If a call is still succeeding, it is a different key. List them — every key the
house has minted comes back with a prefix like flam_sk_Xk4pQ2vB, which is
what tells two keys apart in a log.
"The key gets a 403"
A key holds one of two roles and neither reaches money:
| Role | Reads | Spends tokens | Spends money | Manages keys or seats |
|---|---|---|---|---|
viewer | yes | no | no | no |
member | yes | yes | no | no |
- Developing something with a
viewerkey → 403. Mint amemberkey. - Buying, subscribing, topping up → 403 on any key. Real money is owner-only and
a key can never hold
owner. That ceiling is a database constraint, not a check a future route can forget. - Offering a seat, or minting another key → 403. Key management needs a browser session, because a key that could mint another key could not be revoked: rotating the leaked one would leave the attacker's second key standing.
The worst a leaked key does is spend tokens the house had already bought. Revoke it and carry on.
"The develops from my integration look inconsistent"
Reference order. The studio sends references in the right order for you; over the API you are responsible for it:
- inspiration and base
- the pieces
- the model, last
This is the most common cause of a set that was fine in the browser and drifts through an integration. See the model's face changed between frames.
"My agent can't see progress"
Expected. POST /api/mcp answers initialize, tools/list, tools/call and
ping, and that is a request-response endpoint: GET and DELETE answer 405,
which is how a client learns there is no event stream at that URL.
There are no outbound webhooks. Nothing calls your system back when a develop lands. Poll the job, or watch it in the Darkroom.
What a key costs you
Nothing to mint, and it spends from the same house balance as the studio. An agent developing at 2K is 13 tokens a frame, exactly as a person is. Scope, role and 403s are identical whether a person or an agent asked.
Related
- The API — minting, calling, and the full MCP tool list
- Seats, roles, and who can spend
- What a look actually costs