Skip to content
TriedDocs
Account and security

Users and roles

Invite teammates by email, assign the Admin, Developer or Member role, and see exactly what each role can do.

Each person in a workspace has one of three roles: Admin, Developer or Member. The role is stored on the membership, so the same user can hold different roles in different workspaces. The API checks the role on every request, and the dashboard disables buttons the role cannot use.

Roles#

Role Dashboard description Summary
Admin Full access, including billing and members Everything in the workspace
Developer Build, deploy and monitor agents Every write except workspace administration and billing
Member Read-only access Reads everything a developer can read, writes almost nothing

A workspace always has at least one admin. The API refuses to demote or remove the last admin (A workspace needs at least one admin).

Permissions matrix#

This matrix reflects the role checks in the API (requireRole calls and the member read-only hook).

Action Admin Developer Member
View agents, calls, chats, contacts, analytics Yes Yes Yes
Create, edit, publish and delete agents, LLMs, flows, knowledge bases Yes Yes No
Buy, import and configure phone numbers; batch calls; place calls Yes Yes No
Test LLM and playground simulations in the builder Yes Yes Yes
Run analytics queries and list calls with filters Yes Yes Yes
List, create, edit and delete API keys Yes Yes No
Edit provider fallbacks (PUT /workspace/reliability) Yes Yes No
Remove sensitive data from a call Yes Yes No
Reveal unscrubbed PII on a call (Show PII) Yes No No
Rename workspace, set webhook URL, change concurrency limit Yes No No
Workspace settings (LLM token limit, Conductor limit, webhook timeout) Yes No No
Invite, change role, remove members Yes No No
Transfer or delete the workspace Yes No No
Buy credits, auto-recharge, budget, payment methods, customer portal Yes No No
Submit business verification (KYC) Yes No No
Configure OIDC SSO, SAML and SCIM Yes No No
Read the audit log Yes No No
Leave the workspace Yes Yes Yes

How the member role is enforced#

Members can send GET, HEAD and OPTIONS requests. Any other method returns 403 with The member role is read-only, except for these routes that only read or only affect the member's own account:

  • POST /v3/list-calls
  • POST /agent-playground-completion/... and POST /agent-playground-simulation/...
  • POST /analytics/query
  • /auth/... (sign-in, 2FA, password change)
  • POST /invites/:token/accept
  • POST /workspace/leave
Note

On Settings, Reliability the Save button writes both the provider fallbacks and the workspace settings. The second write is admin only, so a developer who changes the LLM token limit or Conductor limit gets an error.

API keys and public keys#

API keys are not tied to a user. A request with an API key runs with admin-level role checks, then the key's own scopes, IP allowlist and rate limit narrow it. A public key can only start web calls and chats.

Invite a teammate#

Open the Users section#

Go to Settings, Workspace and find Users. Click Invite.

Enter the email and role#

In Invite to workspace, type the email address and choose Admin, Developer or Member. The default role is Member.

Share or wait for the email#

Tried creates an invite link that is valid for 14 days. If the server has SMTP configured, the link is emailed. If not, the dialog says that nothing was sent and shows the link with Copy link, so you can share it yourself.

The Invite to workspace dialog with email and role

The invitee opens the link (/invite/<token>), signs in with any method, and accepts. Accepting adds the membership with the invited role and switches their session to the workspace. An invite can be used once. Expired invites return This invite has expired.

Pending invites appear under Pending invites with their status and expiry. Revoke one with the trash icon (DELETE /workspace/invites/:id). Inviting the same email again replaces the earlier pending invite. Inviting someone who is already a member returns 409.

Email delivery

Invite and password reset emails go through SMTP when SMTP_URL is set on the API (sender SMTP_FROM). Without it, messages are written to the server log and the API response says email_sent: false and email_mode: "log".

Invite API#

curl -X POST https://api.tried.com.au/workspace/invites \
  -H "Authorization: Bearer $TRIED_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "sam@example.com", "role": "developer"}'
{
  "invite_id": "invite_6b1e0f3c9a2d4e7f8a1b2c3d",
  "email": "sam@example.com",
  "role": "developer",
  "accept_path": "/invite/Yk3...",
  "status": "pending",
  "expires_timestamp": 1761878400000,
  "created_timestamp": 1760668800000,
  "email_sent": true,
  "email_mode": "smtp"
}

Add a member directly#

Admins can also add an existing or new user without an invite link: POST /workspace/members with email and role. The user is created if the email is new. This is useful for scripts; most teams use invites.

Change a role or remove someone#

In the Users table, pick a new value in the Role column. You cannot change your own role there. To remove someone, use the remove button on their row and confirm Remove member?.

The Users table with role selectors, and pending invites below
Action API
List members GET /workspace/members
Change role PATCH /workspace/members/:id with { "role": "admin" }
Remove DELETE /workspace/members/:id

Role changes and removals are recorded in the audit log as member.role_change and member.remove.

Provisioning from your identity provider#

With SAML or OIDC SSO, people on your email domains join automatically on first sign-in. With SCIM, your identity provider adds and removes members and sets roles through groups. See SSO, SAML and SCIM.