Migrates a password from your existing system to Stytch for a specific Member.
bcrypt, scrypt, argon2, MD-5, SHA-1, SHA-512, and PBKDF2. This endpoint has a rate limit of 100 requests per second.
If you are using cross-organization passwords (allowing an end user to share the same password across all of their ), call this method separately for each organization_id associated with the given email_address to ensure the password is set across all of their Organizations.Basic authentication header of the form Basic <encoded-value>, where <encoded-value> is the base64-encoded string username:password.
Request type
The email address of the Member.
The password hash. For a Scrypt or PBKDF2 hash, the hash needs to be a base64 encoded string.
The password hash used. Currently bcrypt, scrypt, argon_2i, argon_2id, md_5, sha_1, sha_512, and pbkdf_2 are supported.
bcrypt, md_5, argon_2i, argon_2id, sha_1, sha_512, scrypt, phpass, pbkdf_2 Globally unique UUID that identifies a specific Organization. The organization_id is critical to perform operations on an Organization, so be sure to preserve this value. You may also use the organization_slug or organization_external_id here as a convenience.
Optional parameters for MD-5 hash types.
Required parameters if the argon2 hex form, as opposed to the encoded form, is supplied.
Optional parameters for SHA-1 hash types.
Optional parameters for SHA-512 hash types.
Required parameters if the scrypt is not provided in a PHC encoded form.
Required additional parameters for PBKDF2 hash keys. Note that we use the SHA-256 by default, please contact support@stytch.com if you use another hashing function.
The name of the Member. Each field in the name object is optional.
An arbitrary JSON object for storing application-specific data or identity-provider-specific data.
An arbitrary JSON object of application-specific data. These fields can be edited directly by the frontend SDK, and should not be used to store critical information. See the Metadata resource for complete field behavior details.
Roles to explicitly assign to this Member. Will completely replace any existing explicitly assigned roles. See the RBAC guide for more information about role assignment.
If a Role is removed from a Member, and the Member is also implicitly assigned this Role from an SSO connection
or an SSO group, we will by default revoke any existing sessions for the Member that contain any SSO
authentication factors with the affected connection ID. You can preserve these sessions by passing in the
preserve_existing_sessions parameter with a value of true.
Whether to preserve existing sessions when explicit Roles that are revoked are also implicitly assigned
by SSO connection or SSO group. Defaults to false - that is, existing Member Sessions that contain SSO
authentication factors with the affected SSO connection IDs will be revoked.
The Member's phone number. A Member may only have one phone number. The phone number should be in E.164 format (i.e. +1XXXXXXXXXX).
Whether to set the user's phone number as verified. This is a dangerous field. This flag should only be set if you can attest that the user owns the phone number in question.
If a new member is created, this will set an identifier that can be used in most API calls where a member_id is expected. This is a string consisting of alphanumeric, ., _, -, or | characters with a maximum length of 128 characters. External IDs must be unique within an organization, but may be reused across different organizations in the same project. Note that if a member already exists, this field will be ignored.
Successful response
Globally unique UUID that is returned with every API call. This value is important to log for debugging purposes; we may ask for this value to help identify a specific API call when helping you debug an issue.
Globally unique UUID that identifies a specific Member.
A flag indicating true if a new Member object was created and false if the Member object already existed.
The Member object
The Organization object.
The HTTP status code of the response. Stytch follows standard HTTP response status code patterns, e.g. 2XX values equate to success, 3XX values are redirects, 4XX are client errors, and 5XX are server errors.