Provisions a new Wristband user during the signup flow. This API can be used to perform application-level signups and tenant-level signups:

1. Application-Level Signups: In this case, a new tenant is created, and the user is provisioned under it. To invoke this API for application-level signups, you must provide the following three fields (along with any required user fields):
   1. applicationId
   2. tenantName
   3. tenantDisplayName
2. Tenant-Level Signups: In this case, the user will be provisioned under an existing tenant. To invoke this API for tenant-level signups, you must provide the following field (along with any required user fields):
   1. tenantId

In addition to provisioning the user (and the tenant if performing an application-level signup), this API will also verify the user's email. The strategy for verifying the user's email depends on your application's Signup Workflow policy. Listed below are the supported email verification strategies:

1. User Activation With Email Link: In this case, the user will receive an activation email containing a link that must be clicked to complete activation. Once clicked, the user's status will be set to ACTIVE, their email will be marked as verified, and the user will be redirected to your application's Login Endpoint (or a custom URL if one was configured in the Signup Workflow policy) with an authenticated session, allowing them to immediately log in to your application.

2. User Activation With an OTP: In this case, the user will receive an activation email containing a One-Time Password. The user will need to enter the OTP in the current screen to complete activation. The Activate User API should be called to verify the OTP provided by the user. If the OTP is valid, the user's status will be set to ACTIVE, their email will be marked as verified, and the user will be redirected to your application's Login Endpoint (or a custom URL if one was configured in the Signup Workflow policy) with an authenticated session, allowing them to immediately log in to your application.

3. Email Verification: In this case, the user is provisioned with an ACTIVE status and the response will contain a redirectURL field with a URL that your application should redirect to in order to complete the signup flow. After redirecting to this URL, the user will be sent back to your application's Login Endpoint (or to a custom URL if one was configured in the Signup Workflow policy) with a valid auth session, allowing them to log in to your application immediately. Furthermore, a verification email will be sent asynchronously to the user's email address. When the user clicks the link in the verification email, their email will be marked as verified.

   Note: If MFA enrollment has been marked as required for the user's tenant, then a response with anMFA_ENROLLMENT_REQUIRED result will be returned instead of the SIGNUP_COMPLETED_WITH_EMAIL_VERIFICATION result. In this case, the user must complete the MFA Enrollment workflow before an authenticated session is created. This prevents the user from logging in to your application unless they first enroll in MFA. If the user does not complete MFA enrollment during the signup flow, they will be forced to enroll in MFA when they attempt to log in.

Resending Activation Emails

If either the "User Activation With Email Link" or "User Activation With an OTP" strategy is enabled, and a user already exists, with the specified email under a tenant with a matching name (for application-level signups) or ID (for tenant-level signups), and the user has a status of PENDING_SIGNUP_ACTIVATION, then the provisioning steps will be skipped, and an activation email will be resent for the existing user. This logic allows users who previously signed up but did not complete the activation process to unblock themselves.

Email Verification When Magic Links Are Enabled

If magic links are enabled for the Wristband IdP that the user belongs to, then an activation email will always be sent to the user, even if the Signup Workflow policy is configured to use "Email Verification" as the email verification strategy. This is because magic links can't be used to authenticate a user until the user's email address has been verified.

Required Permissions

Below is the list of required permissions needed to interact with this API. For each permission, the allowed permission boundaries are also specified.