Appearance

Manage user roles ​

Change a user's role from one of OWNER/ADMIN/MEMBER/VIEWER to another, or remove them from the account entirely.

Prerequisites: You must be an OWNER or ADMIN. ADMINs can only assign the role MEMBER or VIEWER — promoting someone to ADMIN requires OWNER.

In the console ​

  1. Go to Account → Users.
  2. Find the user in the list.
  3. Open the row's actions menu and click Change role.
  4. Pick the new role. Save.

To remove a user, click Remove from account in the same menu.

Via the API ​

Change a role ​

PUT /api/v1/users/{id} with the new role:

bash
curl -X PUT https://app.smplkit.com/api/v1/users/$USER_ID \
  -H "Authorization: Bearer $SMPLKIT_API_KEY" \
  -H "Content-Type: application/vnd.api+json" \
  -d '{
    "data": {
      "type": "user",
      "id": "'$USER_ID'",
      "attributes": {
        "role": "ADMIN"
      }
    }
  }'

The endpoint requires OWNER or ADMIN. ADMIN callers get 403 if they try to assign ADMIN or OWNER.

Remove a user ​

DELETE /api/v1/users/{id}:

bash
curl -X DELETE https://app.smplkit.com/api/v1/users/$USER_ID \
  -H "Authorization: Bearer $SMPLKIT_API_KEY"

Returns 204. The user's account_user join row is hard-deleted. If the user belongs to other accounts, those memberships are preserved — only their access to your account is revoked.

Constraints ​

The platform rejects role changes that would leave the account incoherent:

  • The OWNER cannot be demoted via PUT. Trying it returns HTTP 400 with detail "Cannot change the owner's role". Every account has exactly one OWNER, and demoting them would leave the account ownerless. To change the OWNER, see Transfer ownership.
  • The OWNER cannot be removed. DELETE /api/v1/users/{id} on the OWNER returns 400.
  • You cannot remove yourself. The endpoint rejects self-deletion.
  • ADMINs cannot promote to ADMIN. ADMINs can only assign MEMBER or VIEWER. Returns 403 otherwise.

The full role-by-action matrix is on Roles and permissions.

What changes immediately ​

Role changes take effect on the user's next API request — sessions are not invalidated, but the role is loaded fresh from the database on every authenticated request. There's no caching window to wait through.

API keys minted by the user keep working at the role they were minted under. If you need to ensure a downgraded user no longer holds account-write keys, revoke their keys explicitly.

Verify ​

bash
curl https://app.smplkit.com/api/v1/users/$USER_ID \
  -H "Authorization: Bearer $SMPLKIT_API_KEY"

Confirm data.attributes.role matches the new role.