Skip to main content
Create a new API key for a target. The key secret is returned only once.

POST /api-keys/target/:target/:target_id

Path Parameters

target=user mints a key that authenticates as that user rather than as the caller — the only way to act as a service account. target_id names the account, not the caller.

Request Body

A key never grants more than this role, even when its user separately holds a higher-role membership on the target — see Role Cap.

Response

Errors

Minting is a human act: a service account’s own key gets 403 for every target, even one it otherwise administers with admin — this stops a leaked automation key from issuing itself a permanent replacement. Use an acting token when automation genuinely has to mint on a human’s behalf; it carries that human, so it is admitted here at target=user. This is one of ten operations on the access perimeter, all refused on the same terms. target=user is untouched, and is the case acting mode exists for: a human acting as an account, minting that account its own key. org and blob are refused with 400, because such a key authenticates as whoever mints it (user_id, below), and while acting that is the impersonated account rather than the human — a key every perimeter operation would then refuse for the rest of its life, indistinguishable from a working one until it fails. Mint those as yourself; an account is given reach into an Organization or a Blob by membership, not by that target’s own key.

Example

target_target_id is an internal index key the API happens to serialize — safe to ignore, the same as owner_target_target_id on a service account. key is returned only in this response — store it now. Two fields carry the identity of the key, and they are easy to confuse. user_id is the principal the key authenticates as: the target user for a target=user key, or the caller for target=org and target=blob, exactly as before. created_by_user_id is provenance — the human who minted it. They are never the same field: conflating them is the bug service accounts close, where a key’s user_id was always its creator, so an automation key always looked, in the platform’s own records, like whoever set it up.