Roles

Roles are named groups that users belong to. Use roles to control who can access your data and perform specific operations.

User Context

The Current User Context control in the sidebar affects what data you see in Users & Roles. By default, System user is selected with "Skip roles" enabled, giving full access. Change the user context to test what different users would see based on their permissions.

Built-in Roles

Every API includes these system roles that cannot be modified:

JSON Schema	Portal Name	Description
_EVERYONE	Anonymous user	Public access — no authentication required
_AUTHENTICATED_USER	Authenticated user	Any logged-in user
_CREATOR	Owner	The user who created the record

note

The Developer Portal displays user-friendly names (e.g., "Anonymous user"), while the JSON schema uses technical identifiers (e.g., _EVERYONE). Use the JSON schema names when writing access rules in code.

Managing Users

The Users tab shows all users in your API with their authentication details.

User Information

Each user displays:

• Name — User's display name from their identity provider
• Provider — Logo/icon showing which identity provider they authenticated with (Google, Microsoft, Apple, etc.)
• Email — User's email address
• Roles — Assigned role memberships

Sorting and Search

• Sort users by any column
• Use server-side sorting for large user lists
• Search by name, email, or ID

Custom Roles

Create custom roles to match your application's permission model.

Creating a Role

1. Sign in to the Developer Portal
2. Navigate to your API
3. Go to Users & Roles → Roles
4. Click Create Role
5. Enter a role name (e.g., "editor", "viewer", "moderator")

Managing Members

Expand a role to see and manage its members.

Add users to a role:

1. Expand the role row
2. Click Add Members
3. Select users to add

Remove users from a role:

1. Expand the role row
2. Click the delete icon next to the user

Role Assignment

Users can have roles at two levels:

Global Roles

Assigned at the API level. Global roles apply across all collections and views.

Use cases:

• Admin users who need full access
• Moderators who need broad permissions
• Service accounts with specific capabilities

Local Roles

Assigned within specific collections through data relationships. Local roles provide row-level access based on user data.

Use cases:

• Project members who can only access their assigned projects
• Team leads who can manage their team's data
• Users who can only access their own records

Role Priority

When evaluating access:

1. Global roles are checked first
2. If no global role grants access, local roles are checked
3. Access is granted if any matching role permits the operation

Best Practices

• Start restrictive — Begin with minimal permissions and add as needed
• Use descriptive names — "content_editor" is clearer than "role1"
• Prefer roles over individual access — Easier to maintain
• Document your roles — Keep track of what each role is meant for