API keys

​

List keys

​

GET /api/api-keys

• Auth – signed-in, email-verified user.
• Response – array of key views:

[
  {
    "id": "key_123",
    "name": "CI access",
    "accessType": "projects",
    "keyPrefix": "brw_4f8c",
    "createdAt": "2024-05-28T15:23:18.000Z",
    "updatedAt": "2024-05-28T15:23:18.000Z",
    "lastUsedAt": null,
    "projects": [
      { "id": "proj_1", "slug": "marketing-site", "name": "Marketing" }
    ],
    "permissions": null
  }
]

​

Create a key

​

PUT /api/api-keys

• Body

{
  "name": "local-cli",
  "accessType": "projects",
  "projectIds": ["proj_123"]
}

• full – inherits the owner’s permissions. Do not include projectIds or permissions.
• projects – require projectIds (IDs or slugs you already have access to).
• custom – require permissions (permission strings such as marketing.pipelines.read).
• Response

{
  "key": { "...": "same shape as GET" },
  "secret": "brw_live_xxxxx"
}

​

Retrieve / update / delete

​

Using keys

• Send the key with every request via x-api-key or Authorization: ApiKey <secret>. Authorization: Bearer <secret> also works when your client library only supports bearer tokens.
• When both a session cookie and an API key are present, Browsary prefers the more privileged identity (session first, then key).
• Keys scoped to specific projects will receive HTTP 400 errors if they call endpoints outside the allowed list.