Skip to main content

Endpoints

CometChat provides two types of access control permissions: Each type is documented independently below with its own working mechanism, data types, and permission tables.

RBAC (Role-Based Access Control)

Role-Based Access Control (RBAC) enables fine-grained control over what actions a user can perform and what data they can access, based on the role assigned to them (for example: doctor, patient, buyer, seller).

How RBAC Works

  • Permissions are configured per role
  • Each permission has a default value
  • Explicitly configured permissions override defaults
  • RBAC permissions are evaluated at runtime for every API request
  • If a permission evaluation fails, the API returns an ERR_PERMISSION_DENIED error
RBAC supports:
  • Binary permissions (allow / deny)
  • Conditional permissions using additional configuration keys such as mode, allowedRoles, and allowedMessageTypes
Permissions can be restricted by additional conditions such as:
  • User relationships (all users vs friends)
  • Sender or receiver roles
  • Message categories and types

RBAC Data Types

RBAC Permission Structure

Each RBAC permission follows this structure:

RBAC Permission Value Behavior

When an array permission (e.g., allowedRoles, mimeTypes) has a value of null:
  • It means no restriction - all values are allowed
  • This is equivalent to an empty array []
For allow / deny values:
  • allow: The action is permitted
  • deny: The action is blocked, returns ERR_PERMISSION_DENIED
For mode values:
  • all: Action applies to all users
  • friends: Action is restricted to friends only

RBAC Permissions

1. Users

2. Messages

3. Message Thread

4. Message Reactions

5. Calls

6. Conversations

7. Groups

RBAC Example Configuration

The following example denies the sendMessage permission for the user role. When applied, users with this role will not be able to send messages and will receive an ERR_PERMISSION_DENIED error.

RBAC Permission Evaluation Order

  1. Explicitly configured permission for the role which has the highest priority
  2. Permission default value (from permission definition)
If a permission is not explicitly configured for a role, the default value is used.

SBAC (Scope-Based Access Control)

Scope-Based Access Control (SBAC) enables fine-grained control over what actions a user can perform within a group, based on their member scope (for example: admin, moderator, participant).

How SBAC Works

  • Permissions are configured per scope within group context
  • Each permission has a default value
  • Explicitly configured permissions override defaults
  • SBAC permissions are evaluated at runtime for every group-related API request
  • If a permission evaluation fails, the API returns an ERR_PERMISSION_DENIED error
  • SBAC permissions are evaluated alongside RBAC rules. For group operations, both must allow the action
SBAC supports:
  • Binary permissions (allow / deny)
  • Conditional permissions using additional configuration keys such as allowedScopes, allowedMessageTypes, and mimeTypes
Permissions can be restricted by additional conditions such as:
  • Member scopes within the group
  • Message categories and types
  • Group-specific message history access

SBAC Data Types

SBAC Permission Structure

Each SBAC permission follows this structure:

SBAC Permission Value Behavior

When an array permission (e.g., allowedScopes, mimeTypes) has a value of null:
  • It means no restriction - all values are allowed
  • This is equivalent to an empty array []
For allow / deny values:
  • allow: The action is permitted
  • deny: The action is blocked, returns ERR_PERMISSION_DENIED

SBAC Permissions

1. Groups

2. Members

3. Messages

4. Message Thread

5. Message Reactions

6. Calls

SBAC Example Configuration

The following example denies the sendMessage permission for the participant scope. When applied, group members with the participant scope will not be able to send messages in the group and will receive an ERR_PERMISSION_DENIED error.

SBAC Permission Evaluation Order

  1. Explicitly configured permission for the scope which has the highest priority
  2. Permission default value (from permission definition)
If a permission is not explicitly configured for a scope, the default value is used.