Keys

Only a hash is persisted. If you lose the plaintext, revoke the key and mint another — it cannot be recovered.

curl -X POST "https://runlog-7613480744.us-central1.run.app/v1/api-keys" \
  -H "Authorization: Bearer $RUNLOG_SESSION_TOKEN" \
  -H "X-Project-Id: p7Kd2mQx" \
  -H "Content-Type: application/json" \
  -d '{
  "label": "LingCode production",
  "role": "owner"
}'

{
  "createdAt": "2026-08-07T18:00:00Z",
  "key": "rlka_key2Xm9Qd_…",
  "keyId": "key_2Xm9Qd",
  "label": "LingCode production"
}

Integrator provisioning: an Editor-level account key mints `mcp`- and `ingest`-scoped project keys for the projects it just created, so a whole customer setup runs without a browser. The signed-in session calls the same route.

Minting an `api`-scoped project key grants that project to the key itself, so it is an ADMIN act on the project — an editor cannot mint one, and no account key reaches the admin tier: mint `api`-scoped keys from the app.

A project key names no project on its requests: it carries one. Sending `X-Project-Id` for a different project is refused rather than honoured.

The tier is fixed at mint and may not be `admin` — no key of either kind reaches the admin level, so a leaked key can never re-grant access.

curl -X POST "https://runlog-7613480744.us-central1.run.app/v1/mcp-keys" \
  -H "Authorization: Bearer $RUNLOG_API_KEY" \
  -H "X-Project-Id: p7Kd2mQx" \
  -H "Content-Type: application/json" \
  -d '{
  "label": "checkout-service",
  "level": "editor",
  "scope": "api"
}'

{
  "key": "rlk_p7Kd2mQx_key4Bn7Wr_…",
  "record": {
    "createdAt": "2026-08-07T18:00:00Z",
    "keyId": "key4Bn7Wr",
    "label": "checkout-service",
    "level": "ACCESS_LEVEL_EDITOR",
    "projectId": "p7Kd2mQx",
    "scope": "api"
  }
}

The record is kept, marked revoked, so the audit trail survives the credential.

curl -X DELETE "https://runlog-7613480744.us-central1.run.app/v1/mcp-keys/key_2Xm9Qd" \
  -H "Authorization: Bearer $RUNLOG_SESSION_TOKEN" \
  -H "X-Project-Id: p7Kd2mQx"

The site key is the credential and it travels in the body, not the `Authorization` header — the caller is page code, not a server holding a secret. Treat it as public: it grants only what the owner published, and rotating it re-keys the site.

The published set is floored at reads. A write action reaches a PFW only when the owner publishes it explicitly, and no publishing raises a visitor to the admin tier.

60 requests per minute per PFW, not per visitor — a busy site shares one bucket.

The generated `Runlog` client on a published page wraps this route; calling it directly is the same contract.

A visitor signed in on the site's own identity tenant sends their ID token as `Authorization: Bearer`; the dispatch then attributes to them. A token on any other tenant — a Runlog session included — is refused exactly as an unresolvable site is.

curl -X POST "https://runlog-7613480744.us-central1.run.app/v1/public/sites/actions" \
  -H "Content-Type: application/json" \
  -d '{
  "action": "code_context_pack",
  "input": {
    "task": "what does this product do?"
  },
  "key": "site_9Qd2Xm",
  "projectId": "p7Kd2mQx"
}'

{
  "action": "code_context_pack",
  "result": {
    "pack": "…"
  }
}