SaaS backend for teams

In the Anythink dashboard

1. Go to Settings › Data Model, select Add Entity, name it teams and select Create Entity. Add the name and group_id fields.
2. Add another entity called projects. Tick Enable Row-Level Security, then select Create Entity.
3. Add the projects fields from the table. For team, choose Many-to-One and pick teams as the target.

With the CLI

anythink entities create teams
anythink fields add teams name --type varchar --required --name-field
anythink fields add teams group_id --type integer

anythink entities create projects --rls
anythink fields add projects title --type varchar --required --name-field
anythink fields add projects status --type varchar --display select --options "active,archived" --default active
anythink fields add projects team --type many-to-one --target teams
anythink fields add projects team_group_id --type integer

With an AI assistant (MCP)

Create two entities. teams has a required name field that is the name field, and an integer group_id. projects has row-level security on, a required title that is the name field, a select field called status with active and archived and a default of active, a many-to-one field called team that points at teams, and an integer team_group_id.

The assistant runs entities create and one fields add per field through the cli tool. Connect Claude to your backend with MCP sets up the MCP server. For every field type, see Model your data. To switch row-level security on later, or to see what it filters, see Groups and row-level security.

In the Anythink dashboard

1. Open Settings › Users.
2. In the User access card, tick Allow registrations.
3. Choose Team member as the Default role for new users. Administrator roles aren't offered.
4. Tick Require email confirmation for new users if people must confirm their address before they sign in, then select Save.
5. Open Settings › Organisation Settings and add your app's address under Allowed Application URLs. Anythink domains and localhost always work.

With the CLI

These project settings are managed in the dashboard. Use the steps above. Once they're set, registration is an API call, and the CLI can make it for a test:

anythink fetch /auth/v1/register --method POST --body '{
  "first_name": "Alice",
  "last_name": "Smith",
  "email": "alice@example.com",
  "password": "Str0ng!passphrase"
}'

To add someone yourself with a role, invite them. They set their own password from the emailed link:

anythink users invite bob@example.com Bob Jones --role-id 104

With an AI assistant (MCP)

These project settings are managed in the dashboard, and your assistant can walk you through them. Ask it to invite a user instead:

Invite bob@example.com, Bob Jones, as a Team member.

The assistant runs roles list to find the role, then invites the user. Don't paste real passwords into a chat.

In your app, sign in with POST /org/{project_id}/auth/v1/token and send the access token as Authorization: Bearer …. React apps can use the SDK, which stores the session and refreshes it for you. Sign in users covers confirmation, sessions and password resets, and Anythink SDK: sign-in and sessions covers the React side. Manage app users and team members covers inviting, editing and deleting users.

In the Anythink dashboard

1. Open Settings › Users and select the Roles & Permissions tab.
2. Select +, enter Team member, tick API Access and select Create Role. Repeat for Team admin.
3. Select each role. Under Data Model Permissions, tick the actions from the table. For Team admin, find anythink_group_data under Anythink Permissions and tick Read.
4. Select Update Role.

With the CLI

anythink roles create "Team member" --description "A person on a customer team"
anythink roles create "Team admin" --description "Runs a customer team"
anythink roles list

anythink roles permissions list 104

With an AI assistant (MCP)

Create two roles, Team member and Team admin, then show me the permissions on each.

To move a user to a different role later, open them under Settings › Users and change their Role. The change applies on their next request. Roles and permissions covers the settings, field-level access and how to check what a user can do, and Permissions reference lists every permission.

In the Anythink dashboard

1. Open Settings › Organisation Settings. Under Access Controls, tick Enable group-level row access and select Save Changes.
2. Open Settings › Groups and select Create Group. Name it after the team, for example Acme.
3. Open the group, select Add member under Members, choose the user and a role, and select Add member. Members whose role can read the group's data show a Staff badge.
4. Open the team's record in teams and set group_id to the group's id.
5. To share a projects record with the team, open it, choose the Row-Level Security tab, select Add Group Access under Groups, choose the group and select Add Group. Untick Read Only Access to let members edit it.

With the CLI

There's no groups command yet, so call the groups API with fetch:

anythink fetch /groups --method POST --body '{"name":"Acme","description":"Acme Ltd"}'
anythink fetch /groups/4/members --method POST --body '{"user_id":72,"role_id":104}'
anythink fetch /entities/projects/items/42/rls-groups --method PUT --body '{"group_id":4,"readonly":false}'

The group's id comes back from the first call, and anythink roles list shows the role ids. Turn on Enable group-level row access in the dashboard first: there's no CLI command for it.

With an AI assistant (MCP)

Create a group called Acme, add users 72 and 73 to it with the Team member role, and share project 42 with the Acme group so members can edit it.

The assistant finds the role with roles list, then calls the groups endpoints through fetch. Turning on group row access is a dashboard setting.

What each person then sees:

• Members see the records they created, because the creator always gets read-write access to a record, and every record granted to their group. They never see another team's records: those return 404.
• Team admins can also read everything their team's members have created, with a group-scoped read. They send group_scope on the normal list endpoint, using their own access token:

GET /org/{project_id}/entities/projects/items?group_scope=4
Authorization: Bearer <team admin's access token>

The caller must be a member of group 4 whose membership role holds anythink_group_data:read. Anyone else gets 403. A group-scoped read is read-only, and peers don't see each other's records unless a record is granted to the group.

To stamp the team onto records and share them with it automatically, use a workflow. A Create data step can resolve the groups a user belongs to on the server, grant the new record to them and write the group id into team_group_id. Groups and row-level security has the step settings, a worked example and the details of group_scope.

In the Anythink dashboard

1. Open My Account and select the API Keys tab.
2. Enter a Name such as billing-sync and choose Expires in (days).
3. Under Permissions, tick teams:read and projects:read.
4. Select Create API Key, and copy the key from the banner. It's shown once.

With the CLI

anythink api-keys create billing-sync \
  --permissions teams:read,projects:read \
  --expires-in 90 \
  --save-as billing-sync \
  --yes

With --save-as, the key goes into a new CLI profile and is never printed. Use it with anythink --profile billing-sync <command>.

With an AI assistant (MCP)

Create an API key called billing-sync with teams:read and projects:read, expiring in 90 days, and save it as the profile billing-sync.

The assistant runs api-keys create through the cli tool. Ask for --save-as so the key doesn't pass through the conversation.

Call the API from your server like this:

curl "https://api.my.anythink.cloud/org/$PROJECT_ID/entities/projects/items?page=1&pageSize=50" \
  -H "x-api-key: $ANYTHINK_API_KEY"

Keep keys on the server. Never put one in a browser or mobile app. A key can also add people to groups, if an administrator creates it with anythink_groups:read and anythink_groups:update. That's how a signup service on your server can put new users in the right team. Those permissions apply to every group in the project, so keep them on server-side keys and off app roles. See API keys for rotation, revoking and least privilege.

In the Anythink dashboard

1. Open My Anythink and go to your billing account.
2. Select Create Project, choose a plan and name it, for example acme-staging. Repeat for each environment.
3. Open each project from the portal. Check the project name in the header before you change anything.
4. In every project, set Allow registrations, Default role for new users and Allowed Application URLs separately. They aren't shared.

The dashboard has no migrate screen. To copy a data model by hand, create the same entities and fields in the target.

With the CLI

anythink projects create "acme-dev" --region lon1
anythink projects create "acme-staging" --region lon1
anythink projects use acme-dev
anythink projects use acme-staging

anythink migrate --from acme-dev --to acme-staging --include-roles --include-menus --dry-run
anythink migrate --from acme-dev --to acme-staging --include-roles --include-menus

--dry-run prints what would be created and changes nothing. Run it first, and name the profile with --profile on any command that changes data, so you don't land on the wrong project.

migrate copies entities, fields, relationships and, with the flags above, roles with their permissions and menus. It only adds: anything that already exists on the target is skipped. It doesn't copy users, groups, API keys, secrets or settings, so create those in each project. Use --include-settings only on a project whose settings you're happy to overwrite.

With an AI assistant (MCP)

Preview a migration from acme-dev to acme-staging that includes roles and menus. Show me the summary and don't change anything.

The local anythink-mcp server runs migrate through its cli tool. Review the dry-run summary before you ask for the real run.

Before you go live, work through the checklist in Environments and migrating data. Check each role's permissions in production: a missing permission is the most common cause of a 403 after a promotion. Then sign in as a real Team member and a Team admin, and confirm each sees only what they should.