Permissions
Permissions decide which actions a credential may perform on which resources (usually channel or queue names).
Shape
A permission is a JSON object: resource key → list of actions.
{
"notifications": ["subscribe"],
"chat.lobby": ["subscribe", "publish"],
"*": ["subscribe"]
}
| Action | Meaning |
|---|---|
publish | Publish to a channel (also allows enqueue when enqueue is absent) |
subscribe | Subscribe to a channel (also allows dequeue when dequeue is absent). Does not grant platform channels _stats / _logs. |
enqueue | Enqueue jobs on a queue resource |
dequeue | Pull/ack/nack jobs on a queue resource |
stats | Subscribe to the platform _stats channel |
logs | Subscribe to the platform _logs channel |
* | All actions on that resource |
Matching
Permission checks match:
- The exact resource string (channel or queue name), or
- The resource key
"*"(all resources)
Use exact names or "*" in production credentials.
Where permissions are set
- API key — configured in the dashboard when the key is created/updated.
- JWT / token request — optional narrower scope when issuing a token:
await rest.auth.issueToken({
permission: {
"user-42.inbox": ["subscribe"],
},
});
If a token omits permission, the API key’s permissions apply (subject to platform rules).
Examples
Read-only notifications client
{ "notifications": ["subscribe"] }
Server that can publish anywhere and enqueue on emails
{
"*": ["publish"],
"emails": ["enqueue"]
}
Denied publish returns HTTP 403 on REST, or a protocol error on WebSocket.