āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā š shadcn/directory/clerk/clerk-docs/reference/backend/user/create-user ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā
createUser()'
description: Use Clerk's JS Backend SDK to create a user.
sdk: js-backend{/* clerk/javascript file: https://github.com/clerk/javascript/blob/main/packages/backend/src/api/endpoints/UserApi.ts#L140 */}
Creates a User.
Your user management settings in the Clerk Dashboard determine how you should setup your user model. Anything Required in Users & Authentication -> User & authentication will need to be provided when creating a user. Trying to add a field that isn't enabled in Users & Authentication -> User & authentication will result in an error.
Any email address and phone number created using this method will be automatically marked as verified.
[!CAUTION]
This endpoint is rate limited. For development instances, a rate limit rule of 100 requests per 10 seconds is applied. For production instances, that limit goes up to 1000 requests per 10 seconds.
function createUser(params: CreateUserParams): Promise<User>
CreateUserParamsThe ID of the user as used in your external systems. Must be unique across your instance.
firstName?stringThe user's first name.
lastName?stringThe user's last name.
emailAddress[]?string[]Email addresses to add to the user. Must be unique across your instance. The first email address will be set as the users primary email address.
phoneNumber[]?string[]Phone numbers that will be added to the user. Must be unique across your instance. The first phone number will be set as the users primary phone number.
web3_wallet[]?string[]Web3 wallet addresses that will be added to the user. Must be unique across your instance. The first wallet will be set as the users primary wallet.
username?stringThe username to give to the user. Must be unique across your instance.
password?stringThe plaintext password to give the user. Must be at least 8 characters long, and can not be in any list of hacked passwords.
passwordDigest?stringIn case you already have the password digests and not the passwords, you can use them for the newly created user via this property. The digests should be generated with one of the supported algorithms. The hashing algorithm can be specified using the password_hasher property.
passwordHasher?'argon2i' | 'argon2id' | 'awscognito' | 'bcrypt' | 'bcrypt_sha256_django' | 'md5' | 'pbkdf2_sha256' | 'pbkdf2_sha256_django' | 'pbkdf2_sha1' | 'phpass' | 'scrypt_firebase' | 'scrypt_werkzeug' | 'sha256'The hashing algorithm that was used to generate the password digest. The algorithms we support at the moment are:
[!WARNING] For password hashers considered insecure (currently,
MD5andSHA256), the corresponding user password hashes will be transparently migrated tobcrypt(a secure hasher) upon the user's first successful password sign in. Insecure schemes are marked with(insecure)in the list below.
awscognito
password_digest must be in the format of awscognito#<userpoolid>#<clientid>#<identifier>.password_hasher will be updated to bcrypt, and password_digest will be updated to a bcrypt hash.bcrypt
password_digest must be in the format of $<algorithm version>$<cost>$<salt & hash>bcrypt_sha256_django
password_digest must be in the format of (as exported from Django): bcrypt_sha256$$<algorithm version>$<cost>$<salt & hash>bcrypt_peppered
bcrypt except that a pepper string is appended to the input before hashing. When set, password_digest must be in the format of $<algorithm version>$<cost>$<salt & hash>$<pepper>md5 (insecure)
password_digest must be in the format of 5f4dcc3b5aa765d61d8327deb882cf99pbkdf2_sha1
password_digest must be in the format of pbkdf2_sha1$<iterations>$<salt>$<hash-as-hex-string> or pbkdf2_sha1$<iterations>$<salt-as-hex-string>$<hash-as-hex-string>$<key-length>pbkdf2_sha256
password_digest must be in the format of pbkdf2_sha256$<iterations>$<salt>$<hash>pbkdf2_sha512
password_digest must be in the format of pbkdf2_sha512$<iterations>$<salt>$<hash>pbkdf2_sha256_django
password_digest must be in the format of (as exported from Django): pbkdf2_sha256$<iterations>$<salt>$<hash>phpass
password_digest must be in the format of $P$<rounds><salt><encoded-checksum>$P$ is the prefix used to identify phpass hashes.scrypt_firebase
password_digest must be in the format of <hash>$<salt>$<signer key>$<salt separator>$<rounds>$<memory cost>scrypt_werkzeug
password_digest must be in the format of $<algorithm args>$<salt>$<hash>sha256 (insecure)
password_digest must be a 64-length hex string. For example: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08argon2 variants: argon2i and argon2id.
$ character, with the first part identifying the algorithm variant The middle part is a comma-separated list of the encoding options (memory, iterations, parallelism). The final part is the actual digest.password_digest must be in the format of $argon2i$v=19$m=4096,t=3,p=1$4t6CL3P7YiHBtwESXawI8Hm20zJj4cs7/4/G3c187e0$m7RQFczcKr5bIR0IIxbpO2P0tyrLjf3eUW3M3QSwnLcargon2id: $argon2id$v=19$m=64,t=4,p=8$Z2liZXJyaXNo$iGXEpMBTDYQ8G/71tF0qGjxRHEmR3gpGULcE93zUJVUIf you need support for any particular hashing algorithm, contact support.
skipPasswordChecks?booleanWhen set to true, all password checks are skipped. It is recommended to use this method only when migrating plaintext passwords to Clerk. Upon migration the user base should be prompted to pick stronger password.
skipPasswordRequirement?booleanWhen set to true, password is not required anymore when creating the user and can be omitted. This is useful when you are trying to create a user that doesn't have a password, in an instance that is using passwords. You cannot use this flag if password is the only way for a user to sign into your instance.
totpSecret?stringIn case TOTP is configured on the instance, you can provide the secret to enable it on the newly created user without the need to reset it. Currently, the supported options are: <ul><li>Period: 30 seconds</li><li>Code length: 6 digits</li><li>Algorithm: SHA1</li></ul>
backupCodes?string[]If backup codes are configured on the instance, you can provide them to enable it on the newly created user without the need to reset them. You must provide the backup codes in plain format or the corresponding bcrypt digest.
publicMetadata?UserPublicMetadataMetadata that can be read from the Frontend API and Backend API{{ target: '_blank' }} and can be set only from the Backend API.
privateMetadata?UserPrivateMetadataMetadata that can be read and set only from the Backend API{{ target: '_blank' }}.
unsafeMetadata?UserUnsafeMetadataMetadata that can be read and set from the Frontend API. It's considered unsafe because it can be modified from the frontend.
legalAcceptedAt?DateThe date when the user accepted the legal documents. null if Require express consent to legal documents is not enabled.
skipLegalChecks?booleanWhen set to true all legal checks are skipped. It is not recommended to skip legal checks unless you are migrating a user to Clerk.
createdAtstringA custom date/time denoting when the user signed up to the application, specified in RFC3339 format. For example: 2012-10-20T07:15:20.902Z.
</Properties>
const response = await clerkClient.users.createUser({
firstName: 'Test',
lastName: 'User',
emailAddress: ['testclerk123@gmail.com'],
password: 'password',
})
This method in the SDK is a wrapper around the BAPI endpoint POST/users. See the BAPI reference{{ target: '_blank' }} for more information.
ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā