Secrets

Tell the agent where you put it

User-authenticated. Takes a location, never a value — by the time this is called the secret is already in the vault, written by the browser with PUT /v1/vaults/{vault_id}/secrets/{path} over the user's own session. There is no field here that could carry a plaintext credential, and there should never be one.

Fulfilment also grants the asking agent read on exactly that path, and binds the vault to it if the agent has an explicit vault list. Without both, the user hands over a credential and the agent still gets a 403 — the failure this whole flow exists to remove.

post/v1/secret-requests/{id}/fulfil

Request

  • Base URL: https://api.1claw.co
  • URL: https://api.1claw.co/v1/secret-requests/{id}/fulfil
  • Auth: HTTP bearer

Path parameters

idstring uuid required

Request body

vault_idstring uuid required
pathstring required

Example request

{
  "path": "api-keys/x-access-token"
}

Response

Fulfilled

statusstring required
pathstring required
vault_idstring uuid required
granted_readboolean required

False when the secret was stored but the read grant could not be written — the agent will need access granted by hand.

bound_new_vaultboolean

True when the agent had to be bound to a vault it was not bound to before. Its access is correct from now on, but a JWT carries the vault_ids it was minted with, so a token the agent already holds is refused until it re-mints. Answering into a vault the agent already reaches avoids this.

Example response

{
  "status": "fulfilled"
}

Changes

No recorded changes to this operation across all 2 revisions of this API.