Users and permissions

Users are managed per tenant. Creating a user and assigning its permissions is also available in the web interface's user management. With single sign-on, users and their roles come from the customer's identity provider instead; see Users with single sign-on.

Operation: READ, CREATE and UPDATE on users

Purpose	Request
List the users of a tenant	GET /v1/{tenant}/users
Search users by name	GET /v1/{tenant}/users/search/{query}
Read one user	GET /v1/{tenant}/user/{emailOrId}
Create a user	PUT /v1/{tenant}/user/{email}
Update a user, including its permissions	POST /v1/{tenant}/user/{emailOrId}

A user's permissions in a tenant are listed in applicationMetadata.tenants, as the roles assigned to the user. The caller's own profile, with the permissions resolved into operations per object type, is returned by GET /v1/userinfo.

Permission sets

A user's roles are permission sets, objects of type permission, read through the generic endpoints. Each names its grants: an object type, the operations, and optionally an access query that narrows the grant to the records it matches.

Operation: READ on permissions

GET /v1/{tenant}/permissions
GET /v1/{tenant}/permission/{name}

{
  "name": "READ_ALL",
  "mutable": {
    "grants": [
      { "objectType": "assets", "operations": ["READ"], "accessQuery": "" },
      { "objectType": "geos", "operations": ["READ"], "accessQuery": "" }
    ]
  }
}

Field	Description
name	The name of the permission set, as assigned to users
mutable.grants[].objectType	The object type the grant applies to
mutable.grants[].operations	The operations the grant allows: READ, CREATE, UPDATE, DELETE, EXECUTE, COMMISSION
mutable.grants[].accessQuery	Optional. A query that narrows the grant to the records it matches; empty means all records

Permission sets are normally read-only: they are defined with the tenant during onboarding, and with single sign-on the roles a user holds follow from the customer's directory.