clerk-sdk-java/docs/models/operations/UpdateUserRequestBody.md

UpdateUserRequestBody

Fields

Field	Type	Required	Description
externalId	JsonNullable<? extends String>	➖	The ID of the user as used in your external systems or your previous authentication solution. Must be unique across your instance.
firstName	JsonNullable<? extends String>	➖	The first name to assign to the user
lastName	JsonNullable<? extends String>	➖	The last name to assign to the user
primaryEmailAddressId	Optional<? extends String>	➖	The ID of the email address to set as primary. It must be verified, and present on the current user.
notifyPrimaryEmailAddressChanged	Optional<? extends Boolean>	➖	If set to true, the user will be notified that their primary email address has changed. By default, no notification is sent.
primaryPhoneNumberId	Optional<? extends String>	➖	The ID of the phone number to set as primary. It must be verified, and present on the current user.
primaryWeb3WalletId	Optional<? extends String>	➖	The ID of the web3 wallets to set as primary. It must be verified, and present on the current user.
username	JsonNullable<? extends String>	➖	The username to give to the user. It must be unique across your instance.
profileImageId	JsonNullable<? extends String>	➖	The ID of the image to set as the user's profile image
password	JsonNullable<? extends String>	➖	The plaintext password to give the user. Must be at least 8 characters long, and can not be in any list of hacked passwords.
passwordDigest	Optional<? extends String>	➖	In 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	Optional<? extends com.clerk.backend_api.models.operations.UpdateUserPasswordHasher>	➖	The hashing algorithm that was used to generate the password digest. The algorithms we support at the moment are bcrypt, bcrypt_sha256_django, md5, pbkdf2_sha256, pbkdf2_sha512, pbkdf2_sha256_django, phpass, scrypt_firebase, sha256, scrypt_werkzeug and the argon2 variants argon2i and argon2id. If you need support for any particular hashing algorithm, please let us know. Note: for password hashers considered insecure (at this moment MD5 and SHA256), the corresponding user password hashes will be transparently migrated to Bcrypt (a secure hasher) upon the user's first successful password sign in. Insecure schemes are marked with (insecure) in the list below. Each of the supported hashers expects the incoming digest to be in a particular format. Specifically: bcrypt: The digest should be of the following form: $<algorithm version>$<cost>$<salt & hash> bcrypt_sha256_django: This is the Django-specific variant of Bcrypt, using SHA256 hashing function. The format should be as follows (as exported from Django): bcrypt_sha256$$<algorithm version>$<cost>$<salt & hash> md5 (insecure): The digest should follow the regular form e.g.: 5f4dcc3b5aa765d61d8327deb882cf99 pbkdf2_sha256: This is the PBKDF2 algorithm using the SHA256 hashing function. The format should be as follows: pbkdf2_sha256$<iterations>$<salt>$<hash> Note: Both the salt and the hash are expected to be base64-encoded. pbkdf2_sha512: This is the PBKDF2 algorithm using the SHA512 hashing function. The format should be as follows: pbkdf2_sha512$<iterations>$<salt>$<hash> iterations: The number of iterations used. Must be an integer less than 420000. salt: The salt used when generating the hash. Must be less than bytes. hash: The hex-encoded hash. Must have been generated with a key length less than 1024 bytes. pbkdf2_sha256_django: This is the Django-specific variant of PBKDF2 and the digest should have the following format (as exported from Django): pbkdf2_sha256$<iterations>$<salt>$<hash> Note: The salt is expected to be un-encoded, the hash is expected base64-encoded. pbkdf2_sha1: This is similar to pkbdf2_sha256_django, but with two differences: 1. uses sha1 instead of sha256 2. accepts the hash as a hex-encoded string The format is the following: pbkdf2_sha1$<iterations>$<salt>$<hash-as-hex-string> phpass: Portable public domain password hashing framework for use in PHP applications. Digests hashed with phpass have the following sections: The format is the following: $P$<rounds><salt><encoded-checksum> - P is the prefix used to identify phpass hashes. - rounds is a single character encoding a 6-bit integer representing the number of rounds used. - salt is eight characters drawn from [./0-9A-Za-z], providing a 48-bit salt. - checksum is 22 characters drawn from the same set, encoding the 128-bit checksum with MD5. scrypt_firebase: The Firebase-specific variant of scrypt. The value is expected to have 6 segments separated by the $ character and include the following information: hash: The actual Base64 hash. This can be retrieved when exporting the user from Firebase. salt: The salt used to generate the above hash. Again, this is given when exporting the user. signer key: The base64 encoded signer key. salt separator: The base64 encoded salt separator. rounds: The number of rounds the algorithm needs to run. memory cost: The cost of the algorithm run The first 2 (hash and salt) are per user and can be retrieved when exporting the user from Firebase. The other 4 values (signer key, salt separator, rounds and memory cost) are project-wide settings and can be retrieved from the project's password hash parameters. Once you have all these, you can combine it in the following format and send this as the digest in order for Clerk to accept it: <hash>$<salt>$<signer key>$<salt separator>$<rounds>$<memory cost> scrypt_werkzeug: The Werkzeug-specific variant of scrypt. The value is expected to have 3 segments separated by the $ character and include the following information: algorithm args: The algorithm used to generate the hash. salt: The salt used to generate the above hash. hash: The actual Base64 hash. The algorithm args are the parameters used to generate the hash and are included in the digest. argon2i: Algorithms in the argon2 family generate digests that encode the following information: version (v): The argon version, version 19 is assumed memory (m): The memory used by the algorithm (in kibibytes) iterations (t): The number of iterations to perform parallelism (p): The number of threads to use Parts are demarcated by the $ 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. $argon2i$v=19$m=4096,t=3,p=1$4t6CL3P7YiHBtwESXawI8Hm20zJj4cs7/4/G3c187e0$m7RQFczcKr5bIR0IIxbpO2P0tyrLjf3eUW3M3QSwnLc argon2id: See the previous algorithm for an explanation of the formatting. For the argon2id case, the value of the algorithm in the first part of the digest is argon2id: $argon2id$v=19$m=64,t=4,p=8$Z2liZXJyaXNo$iGXEpMBTDYQ8G/71tF0qGjxRHEmR3gpGULcE93zUJVU sha256 (insecure): The digest should be a 64-length hex string, e.g.: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
skipPasswordChecks	JsonNullable<? extends Boolean>	➖	Set it to true if you're updating the user's password and want to skip any password policy settings check. This parameter can only be used when providing a password.
signOutOfOtherSessions	JsonNullable<? extends Boolean>	➖	Set to true to sign out the user from all their active sessions once their password is updated. This parameter can only be used when providing a password.
totpSecret	Optional<? extends String>	➖	In case TOTP is configured on the instance, you can provide the secret to enable it on the specific user without the need to reset it. Please note that currently the supported options are: * Period: 30 seconds * Code length: 6 digits * Algorithm: SHA1
backupCodes	List<String>	➖	If Backup Codes are configured on the instance, you can provide them to enable it on the specific user without the need to reset them. You must provide the backup codes in plain format or the corresponding bcrypt digest.
publicMetadata	Optional<? extends com.clerk.backend_api.models.operations.UpdateUserPublicMetadata>	➖	Metadata saved on the user, that is visible to both your Frontend and Backend APIs
privateMetadata	Optional<? extends com.clerk.backend_api.models.operations.UpdateUserPrivateMetadata>	➖	Metadata saved on the user, that is only visible to your Backend API
unsafeMetadata	Optional<? extends com.clerk.backend_api.models.operations.UpdateUserUnsafeMetadata>	➖	Metadata saved on the user, that can be updated from both the Frontend and Backend APIs. Note: Since this data can be modified from the frontend, it is not guaranteed to be safe.
deleteSelfEnabled	JsonNullable<? extends Boolean>	➖	If true, the user can delete themselves with the Frontend API.
createOrganizationEnabled	JsonNullable<? extends Boolean>	➖	If true, the user can create organizations with the Frontend API.
createdAt	Optional<? extends String>	➖	A custom date/time denoting when the user signed up to the application, specified in RFC3339 format (e.g. 2012-10-20T07:15:20.902Z).