Permissions reference

Every 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.

Last updated

Permissions decide which endpoints a signed-in user or an API key can call. This page is the lookup table: the name of every permission, who has it by default, and what it unlocks. Use it when you build a role or an API key and need to know exactly which boxes to tick.

How permissions work#

A permission name has two parts, {resource}:{action}. The resource is an entity (orders) or a platform feature (anythink_files). The action is one of four verbs.

Action Lets the caller
read List and fetch items
create Add new items
update Change existing items
delete Remove items

One resource, anythink_workflows, adds a fifth action, trigger, which runs a workflow.

  • Permissions sit on roles and on API keys. A signed-in user gets the permissions of their role. An API key carries the list you chose when you created it. See API keys.
  • Each endpoint checks one permission. A caller without it gets 403 Forbidden.
  • Administrators bypass permissions. A user whose role is an administrator role can call everything. The Admin User role holds no permission rows because it doesn't need any.
  • Row-level security applies on top. Holding orders:read lets you call the endpoint. With row-level security on, you still only see the records you've been granted. See Groups and row-level security.

Note: A role also needs API Access ticked before its users can read or write entity records over the API. Other areas, such as files and dashboards, use their own permissions.

Entity permissions#

Every entity you create gets four permissions: {entity}:read, {entity}:create, {entity}:update and {entity}:delete. For an entity called orders they are orders:read, orders:create, orders:update and orders:delete. They're created when the entity is created and removed when it's deleted.

New entity permissions are given to administrator roles only. No other role, including Standard User, receives them. To let someone work with orders, tick the permissions on their role or put them on an API key.

In the Anythink dashboard they're listed under Data Model Permissions. The REST endpoints they guard are the entity item endpoints: GET, POST, PUT and DELETE on /org/{project_id}/entities/{entity}/items, plus bulk create, import and delete-many.

System permissions#

Platform features use resources that start with anythink_. Your project has 92 system permissions. In the dashboard they appear under Anythink Permissions. They fall into three groups by who holds them by default.

  • Standard User: the role every new project starts with. It holds the permissions in the first table (42 of them).
  • Administrators only: nobody but administrators holds them unless you tick them on another role (45 permissions).
  • Opt-in: nobody holds them until you tick them, because the feature is an add-on (5 permissions).

The Admin User role, and any other administrator role, can use all of them.

Tick only the actions listed under What it allows. A few resources also list further actions in the dashboard. Granting those unlocks nothing.

All paths below start with /org/{project_id}.

Held by Standard User#

Permission Actions What it allows
anythink_documentation read Read the project's built-in documentation (/docs).
anythink_entities read create update delete List and fetch entities, enums, charts and materialised views, with read. Create, change and delete entities, charts and materialised views with the other three.
anythink_fields read create update delete List, add, change and remove the fields of an entity (/entities/{entity}/fields).
anythink_workflows read create update delete trigger read lists workflows and their runs. create adds workflows and steps. update edits them. delete removes them. trigger runs a workflow on demand.
anythink_files read create update delete read lists and downloads files and folders. create uploads files and makes folders. update renames, moves and re-probes. delete removes files and folders.
anythink_secrets read create update delete read lists secret names (values are never returned). create adds a secret, update rotates one, delete removes one. See Store API keys and tokens as secrets.
anythink_integrations read create update delete read lists integrations and connections, and runs integration operations. create adds a connection. update edits one. delete removes one.
anythink_ai_chat read create update delete Use the AI assistant in the Anythink dashboard: list conversations and models, start conversations and send messages, rename and delete conversations.
anythink_dashboards read create update delete read opens dashboards and previews charts and widgets. create makes a dashboard. update edits it and sets the home dashboard. delete removes it.
anythink_tenant_devices create Register a push device for the signed-in user. Registering a device for another user needs an administrator or an API key with this permission. See Push notifications.
anythink_modules read create update delete Reserved. No endpoint checks it, so ticking it changes nothing.

Administrators only#

Permission Actions What it allows
anythink_menus read create update delete Read, create, edit, reorder and delete dashboard menus and their items.
anythink_roles read create update delete List, create, edit and delete roles. update also changes a role's field-level access.
anythink_permissions read create update delete List, create, edit and delete permission records.
anythink_users read create update delete read lists and fetches users. create adds a user. update edits one, marks them confirmed and sends confirmation or invitation emails. delete removes one. See Sign-in.
anythink_user_profiles read update Read and update user profiles (/user-profiles). Kept administrator-only because the endpoint otherwise limits non-administrators to their own profile.
anythink_payments read create update read lists payments and looks one up. create records a payment or charges a saved payment method. update confirms or captures a payment intent. See How payments work.
anythink_subscription_plans read Read plans, payment options and subscription templates, and a subscriber's own entitlement and offer codes (/subscriptions/me/entitlement, /offers/me/...). This is the permission subscribers need. Creating and changing plans needs an administrator.
anythink_subscriptions read create update delete Reserved. No endpoint checks it, so ticking it changes nothing.
anythink_offers read create update delete read lists offers, codes and redemptions. create adds offers and codes. update edits an offer. delete removes one.
anythink_balances read update read shows user balances, history and holders. update adjusts a user's balance.
anythink_ai_config read update read shows the AI assistant's configuration and usage. update changes the configuration.
anythink_tenant_push_categories update Sync push notification categories from an app (/push/categories/sync). Grant it to the role or key your app uses.

Opt-in#

Permission Actions What it allows
anythink_groups read create update delete read lists groups, their members and the caller's own groups. create adds a group. update renames a group and manages its members. delete removes a group.
anythink_group_data read Read records owned by any member of a group the role belongs to, through a group-scoped request. See Groups and row-level security.

Note: Anythink adds new default permissions to the Standard User role in existing projects when they're first created. It never re-adds one you've since removed.

Endpoints that need administrator access#

These endpoints check that the caller is a project administrator. Permissions don't unlock them, and an API key can't call them. All paths start with /org/{project_id}.

Area Endpoints
Project PUT / to update the project, GET /storage for storage usage, POST /cors/clear-cache.
Row-level security GET, PUT and DELETE on /entities/{entity}/items/{id}/rls-users and /rls-groups.
Email All of /email-templates, including the shell and previews. Custom sending domains and sender addresses: /tenant-domains and /tenant-sender-addresses, including verify, default and avatar.
Search POST /search/rehydrate and /search/rehydrate/{entity}. DELETE /search/purge and /search/purge/{entity}.
Push notifications /push/credentials (read, set Firebase and web push credentials, delete, device source), GET /push/devices, DELETE /push/devices/{id}.
Payments Stripe Connect (/integrations/anythinkpay/stripe-connect/...), Apple in-app purchase credentials and test notifications, creating, changing and deleting subscription-plans and subscription-templates, and changing or removing a subscription's users.

Grant permissions#

Pick the target first. A role gives the permissions to every user who has it. An API key gives them to one script or server.

In the Anythink dashboard

For a role:

  1. Open Settings › Roles and permissions and select the role, or create one.
  2. Make sure API Access is ticked.
  3. Under Data Model Permissions, tick the actions for each entity the role needs.
  4. Under Anythink Permissions, tick the actions for each platform feature, for example Read on anythink_subscription_plans.
  5. Save the role.

For an API key, open My Account, select the API Keys tab and tick the same permissions under Permissions when you create the key. See API keys.

With the CLI

Manage role permissions in the Anythink dashboard. Use the CLI to create a role and to check what it holds:

bash
anythink roles create editor --description "Edits content"
anythink roles list
anythink roles permissions list 239

For an API key, the CLI works end to end:

bash
anythink api-keys create nightly-export \
  --permissions orders:read,customers:read \
  --expires-in 90 \
  --save-as nightly-export \
  --yes

--permissions takes the exact names from this page. To see every permission that exists in your project:

bash
anythink fetch /permissions

A key can only hold permissions its creator holds. If you ask for one the creator lacks, the CLI warns you which were dropped.

With an AI assistant (MCP)

With the local MCP server (anythink-mcp), the assistant can list roles, show what a role holds and create API keys:

List my roles and show the permissions on Standard User.

Create an API key called nightly-export with orders:read and customers:read, expiring in 90 days, and save it as the profile nightly-export.

Ask it to use --save-as so the key goes into a profile and never passes through the conversation. Change a role's permissions in the Anythink dashboard.

Common sets#

Each set lists the permissions to tick. Replace the entity names with your own.

A read-only key#

For a report, an export or a dashboard that only reads.

  • orders:read
  • customers:read
bash
anythink api-keys create reporting --permissions orders:read,customers:read --expires-in 30 --save-as reporting --yes

The role for your app's signed-in users#

Create a role of its own for people who use your app, and choose it as the Default role for new users under Settings › Users. Standard User is meant for your team and can create and delete entities and secrets, so don't use it for app users.

  • Entity permissions for what users do in your app, for example orders:read and orders:create
  • anythink_files:create and anythink_files:read, if users upload or view files
  • anythink_tenant_devices:create, if the app registers for push notifications

Tick API Access. Pair the entity permissions with row-level security so each user only sees their own records.

A content editor#

For someone who edits content in the Anythink dashboard but doesn't change the data model.

  • read, create, update and delete on each content entity, for example blog_posts:read, blog_posts:create, blog_posts:update and blog_posts:delete
  • anythink_files:read, anythink_files:create, anythink_files:update and anythink_files:delete
  • anythink_dashboards:read
  • anythink_entities:read and anythink_fields:read, so the dashboard can show the entities and their fields

Leave the other actions on anythink_entities and anythink_fields, and all of anythink_roles and anythink_users, unticked. They are the permissions that change structure and access.

A subscriber#

For a user who buys or manages a subscription through your app.

  • anythink_subscription_plans:read

That one permission covers the subscriber-facing endpoints: payment options, plans, their own entitlement and their own offer codes. See How payments work and Payments recipes.

Next steps#