Member
Response structure for an enterprise user
Fields
createdAtString!RequiredenterpriseIdInt!RequiredgrantedPermissions[EnterprisePermission!]!RequiredhasPermissionBoolean!RequiredpermissionEnterprisePermission!RequiredidInt!RequiredisActiveBoolean!Requiredroles[RoleInfo!]!RequiredupdatedAtString!RequireduserEmailString!RequireduserIdInt!RequireduserNameString!Required
Timestamp when the user was added to the enterprise
ID of the enterprise this user belongs to
Every permission this member holds, deduped across their roles and with wildcards expanded — the union of roles[].permissions, flattened so a client does not have to compute it.
Named in SCREAMING_SNAKE_CASE, so the enterprise.users.view listed under roles[].permissions appears here as USERS_VIEW. Match on these values rather than on those strings.
A permission the platform no longer recognises is left out; it grants nothing either way.
Advisory only — the server checks again on every field this would gate.
Whether this member holds permission.
Derived from grantedPermissions, so the two can never disagree.
Advisory only — the server checks again on every field this would gate.
The permission to test for.
Unique identifier for the enterprise user record
Whether the user is active in the enterprise
List of roles assigned to this user
Timestamp when the user record was last updated
Email address of the user
ID of the base user record
Full name of the user
Built with