Roles and permissions

Every person who signs in to your project has one role. The role decides what they can do. This page shows how to create roles, give them permissions, put users on them and check the result, in the Anythink dashboard, the CLI and with an AI assistant.

For the name and meaning of every individual permission, see the Permissions reference. This page is the how-to.

How access works

Three layers decide what a request can do. Each one narrows the one before it.

Layer	Question it answers	Where you set it
Role permissions	May this user read, create, update or delete `orders` at all, or use a platform feature such as files?	This page
Field access	Which fields of `orders` can this role see?	This page
Row-level security	Which `orders` records can this user reach?	Groups and row-level security

A role holds permissions. A permission is named {resource}:{action}, such as orders:read or anythink_files:create. A user gets exactly the permissions on their role. A request that needs a permission the role lacks returns 403 Forbidden.
Project administrators bypass permissions. A user on the Admin User role passes every permission check, bypasses field access and row-level security, and can call the administrator-only endpoints. The role holds no permission rows because it doesn't need any. You can't create other administrator roles.
Standard User is a starting point, not a default. Every project starts with two roles, Standard User and Admin User. Standard User holds the everyday platform permissions (entities, fields, workflows, files, secrets and more) and starts with no permissions on your own entities. It is meant for your team. It can create and delete entities and secrets, so don't hand it to the people who use your app.
New users get the default role you choose. When someone registers themselves, or signs in for the first time with a social provider, they get the role set as Default role for new users. No role is chosen for you. While none is set, registration is refused. See Sign-in.
Row-level security sits on top. Holding orders:read lets a role call the endpoint. With row-level security on for orders, a user still only sees the records they've been granted.
Changes apply straight away. Permissions are checked on every request, so a user doesn't need to sign in again after you change their role or its permissions.

View and create roles

Find the role you want to change, or make a new one.

A role has these settings:

Setting	What it does
Name	Up to 50 characters, unique in the project. The dashboard accepts letters, numbers and spaces.
Description	Up to 255 characters. Shown in the roles table.
Is Active	Inactive roles aren't offered when you pick a role for a user.
API Access	Lets users on the role call the data endpoints for your own entities (`/entities/{entity}/items`). Off, those calls return `403` whatever permissions the role holds. A role can only hold permissions while this is on: permissions are saved only when API Access is ticked. Platform features such as files and workflows follow their own permissions and don't depend on it.
External Application URL	Where the confirmation and invitation emails for users on this role send them after they've confirmed. Use it when a role belongs to your own app rather than the Anythink dashboard.

Admin User can't be edited or deleted. A role can't be deleted while any user is on it. Move those users to another role first.

In the Anythink dashboard

Open Settings › Users and select the Roles & Permissions tab. Only project administrators see it.
The table lists each role with its description, whether it's active, whether it has API Access, and whether it's locked.
To create a role, select the + button, enter a Role Name, and tick API Access if the role will work with your entities. Select Create Role.
To change a role, select its name. Edit the details and select Update Role.
To delete a role, use the menu at the end of its row and choose Delete.

With the CLI

bash

anythink roles list
anythink roles create editor --description "Edits content"

roles list shows each role's ID, name, description and whether it's active. Note the ID: the other commands on this page use it.

roles create makes an active role. It starts with API Access off, so open the role in the Anythink dashboard and tick API Access before you grant it permissions on your entities.

To delete a role that no user is on:

bash

anythink roles delete 106 --yes

With an AI assistant (MCP)

With the local MCP server (anythink-mcp), the assistant runs the same commands:

List the roles in this project.

Create a role called editor with the description "Edits content".

Tell it to remind you to tick API Access in the Anythink dashboard afterwards. The assistant in the dashboard can list roles and read one (roles list, roles get). It can't create them, so use the dashboard steps above there.

Give a role permissions

There are two kinds, shown in two tables on the role's page. A role needs both kinds for most jobs.

Entity permissions control your own data. Each entity has read, create, update and delete. In the dashboard they're under Data Model Permissions, and the table only appears while API Access is ticked. New entities start with permissions held by administrators only, so every other role needs them ticked.
System permissions control platform features such as files, dashboards, secrets and users. Their names start with anythink_. In the dashboard they're under Anythink Permissions. Tick only the actions the Permissions reference lists for each one.

Saving a role replaces its permissions with exactly the boxes you've ticked. Untick a box to take a permission away.

In the Anythink dashboard

Open Settings › Users, select Roles & Permissions, and select the role.
Make sure API Access is ticked.
Under Data Model Permissions, tick Read, Create, Update and Delete for each entity the role works with.
Under Anythink Permissions, tick the actions for each platform feature the role needs.
Select Update Role.

To hide individual fields from the role, select the gear in the Field Access column on an entity's row, switch off the fields, and select Save Field Access. Fields are visible unless you switch them off. id, created_at and updated_at are always visible. People on an administrator role see every field. A hidden field no longer appears in the entity's definition or in query results for that role.

With the CLI

Manage a role's permissions in the Anythink dashboard. The CLI can show you what a role holds:

bash

anythink roles permissions list 104

text

── Role Standard User — Entity Permissions (18 entities) ───────────
│ anythink_files    │ read, create, update, delete │
│ blog_posts        │ read, create, update         │

The table lists both your entities and the anythink_ system resources, with the actions the role holds on each.

To see every permission that exists in the project, with its ID:

bash

anythink fetch /permissions

To see which fields a role can see on an entity, and to change that, use the field access endpoints. Take the entity's ID from anythink fetch /entities/blog_posts:

bash

anythink fetch /roles/104/field-access/entities/365

anythink fetch /roles/104/field-access --method POST \
  --body '{"entity_id":365,"field_access":[{"field_id":1273,"is_active":false}]}'

The POST replaces the saved settings for that entity. Fields you leave out stay visible.

With an AI assistant (MCP)

Your assistant can show what a role holds:

Show the permissions on the Standard User role.

Change a role's permissions in the Anythink dashboard.

Assign roles to users

Every user has exactly one role in a project. Pick it when you add the user, and change it whenever their job changes. The picker doesn't offer inactive roles or administrator roles. For inviting people, passwords and access across several projects, see Manage app users and team members.

In the Anythink dashboard

To add a user with a role:

Open Settings › Users and select the + button.
Enter the name and email address, and choose the Role.
Select Create User. The user is sent an invitation.

To change a user's role:

Open Settings › Users and select the user.
Under Edit User, choose a different Role.
Select Update User.

To choose the role people get when they register themselves, open Settings › Users and use the Default role for new users setting in the User access card. It's covered in Sign-in.

With the CLI

bash

anythink users list
anythink users invite alice@example.com Alice Smith --role-id 104

users list shows each user's role. users invite creates the user and sends the invitation. Always pass --role-id.

To move an existing user to another role, send the update yourself. Send their current first and last name too, because the update saves all three values:

bash

anythink fetch /users/21 --method PUT \
  --body '{"first_name":"Alice","last_name":"Smith","role_id":131}'

With an AI assistant (MCP)

List my users and their roles.

Move user 21 to the editor role.

The assistant looks up the role ID with roles list, then sends the update through fetch. The default role for new users is a project setting, so change it in the Anythink dashboard.

Recipes

Replace the entity names with your own. Each role needs API Access ticked. Create the role, then tick the permissions in the Anythink dashboard as described above.

An editor who can change content but not settings

For someone who writes and publishes content in the Anythink dashboard and shouldn't touch the data model, users or access.

Permission	Why
`blog_posts:read`, `create`, `update`, `delete`	Work with each content entity
`anythink_files:read`, `create`, `update`, `delete`	Upload and manage images and documents
`anythink_entities:read`	Let the dashboard load each entity's definition
`anythink_fields:read`	Let the dashboard load each entity's fields
`anythink_dashboards:read`	Open dashboards

Leave the create, update and delete boxes under anythink_entities and anythink_fields unticked, and everything under anythink_roles, anythink_permissions, anythink_users, anythink_menus and anythink_secrets. They change structure and access. Give the editor a focused sidebar with a menu for the role: see Menu configuration.

A read-only reviewer

For someone who looks at records but can't change them.

Permission	Why
`blog_posts:read`, `orders:read`	Read each entity
`anythink_entities:read`, `anythink_fields:read`	Let the dashboard describe the entities
`anythink_files:read`	View files, if the records have them

Don't tick create, update or delete anywhere. To hide a sensitive field such as cost_price, switch it off under Field Access for this role.

The role for your app's end users

For the people who sign in to the app you build on Anythink. Don't use Standard User for them.

Create a role named for the audience, such as Customer. Tick API Access.
Tick only what the app does: for example orders:read and orders:create, and anythink_files:create and anythink_files:read if people upload files.
Set it as the Default role for new users under Settings › Users.
Turn on row-level security for the entity, so each person only sees their own records. See Groups and row-level security.

Build your first app walks through this end to end.

Check what someone can do

There's no single "can this user do X" lookup for another person. The reliable checks are these.

1. See the role and what it holds. A user can do what their role holds, plus everything if the role is an administrator role. Open the user, read their role, then read the role's permissions.

bash

anythink users get 21
anythink roles permissions list 104

2. Ask as the user. These endpoints answer for whoever is signed in, using the same checks every request goes through. Call them with the user's own access token:

Request	Answers
`GET /org/{project_id}/users/me/permissions`	Every permission the signed-in user holds
`GET /org/{project_id}/users/me/has-permission?permissionName=orders:update`	`true` or `false` for one permission
`GET /org/{project_id}/users/me/has-role?roleName=Customer`	`true` or `false` for one role
`GET /org/{project_id}/users/me/is-admin`	`true` for a project administrator
`GET /org/{project_id}/users/me`	The user, including `role_name` and `can_access_any_api`

Administrators get true for every permission name. For a role with API Access off, has-permission still reports the permissions the role holds, so also check can_access_any_api in GET /users/me: it must be true before the user can call your entity endpoints.

Your app can use these to show or hide buttons. The API enforces permissions on every call regardless.

3. Try it. The surest test is to sign in as a user on the role and make the request. A request without the permission returns 403. See Sign-in.

The CLI signs in as you, not as your end users, so anythink fetch /users/me/permissions shows your own permissions. Use anythink users me to confirm which account the CLI is using.

With an AI assistant (MCP)

What role is user 21 on, and what can that role do?

The assistant reads the user and the role. It acts as the account you signed the MCP server in with, so it can't answer for the user's own session.

Limits

One role per user per project. Roles don't stack. To give someone a mix of access, build a role that holds it.
Roles are per project. A role and its permissions exist in one project only. A person who belongs to several projects has a role in each.
No custom administrator roles. Administrators are the people on Admin User. It can't be edited or deleted.
Role changes in the Anythink dashboard. Roles and permissions are edited in the dashboard. The CLI and MCP can list and create roles and read what they hold.
Permissions control actions, not records. Roles can't limit which records a user sees. Use row-level security for that.
Menus aren't access control. Hiding a sidebar link doesn't stop a person using the page. Remove the permission instead. See Menu configuration.
API keys carry their own permissions. An API key holds the list you chose when you created it, not a role. See API keys.
Administrator-only endpoints. A few endpoints need an administrator and can't be unlocked with a permission. They're listed in the Permissions reference.
A role in use can't be deleted. Move its users first.

Next steps

Permissions referenceEvery permission name in your project: how names work, which roles hold them by default, what each one unlocks, and how to grant them to roles and API keys.

Manage app users and team membersList, find, invite, edit and delete the users who sign in to your app, add them to groups, and see how they differ from your project's team members.

Groups and row-level securityPut users in groups and grant records to those groups, so row-level security scopes reads and writes without impersonation endpoints.

Menu configurationChoose what appears in the Anythink dashboard sidebar for each role. Create a menu, add, nest and reorder items, and keep access control in permissions.

API keysCreate and scope API keys for server-to-server calls, rotate a leaked key, and see exactly which permissions a key needs.

Sign in users: email, tokens and API keysRegister and sign in users with email and password, manage sessions with access and refresh tokens, reset passwords, and know when to use an API key.