Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.wisdom.ai/llms.txt

Use this file to discover all available pages before exploring further.

The createUsers mutation provisions one or more users in a workspace. Call this before impersonating a user in the embedded flow — a user must exist before they can be impersonated.

​
Signature

createUsers(input: CreateUsersInput!): CreateUsersResponse!

​
Arguments

​
input
CreateUsersInput!
required
Input object containing the details for the users to create.

​
CreateUsersInput fields

​
emails
[String!]!
required
One or more email addresses to provision. User matching is email-based — each email must be unique within the workspace.
If your embedded users may share email addresses across tenants (e.g., the same person is a customer of multiple clients), append a unique identifier to the email prefix: alice+tenant123@yourcompany.com. This prevents cross-tenant session collisions.
​
workspaceID
ID
The workspace to create the users in. Required for multi-workspace deployments.
​
roleAssignments
[RoleAssignmentInput!]
Role assignments for the new users. Each entry specifies a roleId and scopes. See RoleAssignmentInput.For embedded dashboards, assign the Viewer role to hide edit controls:
[{ "roleId": "00000000-0000-0000-0000-000000000003", "scopes": ["{{DOMAIN_ID}}"] }]
​
sendWelcomeEmail
Boolean
Whether to send a welcome email to the new users. Default: false. Set to false for programmatically provisioned embedded users.
​
userAttributes
[UserAttributeInput!]
Key-value pairs for parameterized connections and row-level data access. These are stored as DATABASE-sourced attributes. See User attributes.
​
userGroupIds
[ID!]
Optional group IDs to assign the users to on creation.
CreateUsersInput does not include a display name field. Users provisioned via this mutation appear as their email address in the WisdomAI admin screen. If a display name is needed, pass it as a userAttributes entry (for example, { "key": "display_name", "value": "Alice Smith" }).

​
Response

​
status
ResponseStatus!
Indicates whether the operation succeeded. See ResponseStatus.
The status field here returns a ResponseStatus object (with code and message). This is distinct from the UserStatus enum (e.g., ACTIVE) found on the User object.

​
Usage example

mutation CreateUsers($input: CreateUsersInput!) {
  createUsers(input: $input) {
    status {
      code
      message
    }
  }
}

curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <access_token>" \
  -d '{
    "query": "mutation CreateUsers($input: CreateUsersInput!) { createUsers(input: $input) { status { code message } } }",
    "variables": {
      "input": {
        "emails": ["alice@yourcompany.com"],
        "workspaceID": "workspace_123",
        "roleAssignments": [{ "roleId": "00000000-0000-0000-0000-000000000003", "scopes": ["{{DOMAIN_ID}}"] }],
        "sendWelcomeEmail": false
      }
    }
  }' \
  https://{ACCOUNT}.askwisdom.ai/graphql

{
  "data": {
    "createUsers": {
      "status": {
        "code": "OK",
        "message": "Users created successfully"
      }
    }
  }
}
If a user with the same email already exists, the call succeeds but re-applies the role assignments you pass in, overwriting any manually assigned roles. To avoid resetting roles on existing users, check listUsers first and skip createUsers for users already provisioned.

Set user attributes

Update attributes on existing users

Impersonate user

Generate a session JWT for the created user

User attributes

How attributes control data access

Embedding overview

Full server-side embedding flow