Authentication
Opaque bearer keys, workspace isolation and explicit permissions.
Authenticate on the server
Pass your opaque API key in Authorization: Bearer <key>. It is not a JWT. Your application should call muwkl from a trusted server; never place a key in client-side JavaScript, a URL or analytics events.
Authorization: Bearer <your-workspace-key>
Content-Type: application/jsonGrant only the scopes you need
Scopes are independent. A write key does not automatically gain read access. An agent-bound key also has to match the agent involved in the operation.
| Scope | Use |
|---|---|
| read | Read permitted configuration and conversation records |
| write | Create agents and change their configuration or lifecycle |
| converse | Create conversations and submit messages |
The credential chooses the workspace
Do not send tenant, tenant_id or another tenant selector. These are rejected, rather than used to switch workspaces. Use the appropriate credential for each workspace.
Manage the key’s lifecycle
Keep the raw key private when it is issued. If it is exposed, revoke it through workspace management and replace it in your server secret store. Check permissions when a request returns 403; do not broaden scopes merely to silence an error.
Need a hand? Get in touch