Keys, members and consumer access

These endpoints require workspace-wide org:manage unless the catalog lists another gate. A project-restricted consumer key should not administer workspace access.

API keys

GET /api-keys lists metadata. POST accepts name, nonempty scopes, optional readPermissions, projectIds, workspaceResources and expiresAt. It returns {key} with the one-time secret on creation. Store the secret outside logs.

PATCH /api-keys/{keyId} updates projectIds, workspaceResources and/or readPermissions. These arrays replace the corresponding grants; it does not edit name, scopes or expiry. DELETE revokes the key. Rotate by creating and validating a replacement, updating the consumer and then revoking the old key.

Existing members

GET /members lists existing membership with cursor paging. GET/PUT member read-permissions reads/replaces {readPermissions:[...]}. GET/PUT write-permissions reads/replaces {permissions:[...]} with allowed values policy:read, policy:propose, policy:approve, policy:manage, data:write, data:delete, data:maintain.

{"readPermissions":["maintenance:read"]}

This is a complete replacement body for an existing member's named read grant set, not an invitation or a workspace role change. Public routes do not create memberships, configure SSO or change owner/admin roles.

Consumer modes and traffic

GET/PUT /semantic-api reads/sets {mode:"disabled"}, {mode:"read_only"} or {mode:"read_write"}. GET/PUT /source-write-settings sets read_only/read_write for governed source writes. Mode enables an interface; it does not grant every caller access.

GET/PUT /api-limits sets positive integer workspaceRequests and apiKeyRequests. The response identifies the window duration. Adjusting traffic limits does not reset plan usage or approve writes.

See Workspace management for ownership, membership, policies and the platform setup behind these HTTP controls.