This method sets account data into a user's account. The method accepts a list of optional parameters each defining a field/object in the account. The parameters that are passed in the request modify the relevant fields, and the other fields remain unchanged.
Do not use this API to create new fields within your site schema, use the REST API accounts.setSchema.
Security and Write Access
Data written from the server side is considered more reliable. For this reason, we recommend using this method from the server-side rather than from your web client. Pass the relevant data to your server and call accounts.setAccountInfo from your server.
When you are not using the UI Builder to customize Screen-Sets and are manually calling the current method, you need to make sure that the relevant schema fields can be written to. By default, all the data fields in the Accounts Storage have a serverOnly write access, which means that only signed requests coming from server are allowed to write into these fields. You can view the access defined for your fields by calling accounts.getSchema. If you wish to use this method from the client side, you will need to ensure the relevant fields can be written to, prior to using this method. Change the write access of all the fields you wish to set from the client side to clientModify using the accounts.setSchema API method. Otherwise you will receive the "Schema validation failed" error (errorCode 400020) in the method response.
For additional information see our Security Best Practices guide.
The following table lists the available parameters:
||addLoginEmails||string||A comma-separated list of emails that should be added to the user's login identifiers list, and can be used for login purposes.|
A reference to a callback function. Gigya calls the specified function along with the results of the API method when the API method completes.
The callback function should be defined with the following signature: functionName(Response).
The "Response Object Data Members" table below provides specification of the data that is passed to the callback function.
A string of maximum 100 characters length. The CID sets categories for transactions that can be used later for filtering reports generated by Gigya in the "Context ID" combo box. The CID allows you to associate the report information with your own internal data. For example, to identify a specific widget or page on your site/application. You should not define more than 100 different context IDs.
|||conflictHandling||string||How the server handles a "login identifier exists" conflict on a new account:|
A developer-created object that is passed back unchanged to the application as one of the fields in the response object.
|||data||JSON object||An object containing custom data. Any data that you want to store regarding the user which isn't part of the profile or subscriptions objects can be stored here.|
Note that when using this parameter for users that already have custom data stored, it is not necessary to set all the fields again. Just include the fields you want to change or add. For example, the following code adds a "car" field to the user's custom data with the value "Suzuki Alto", or, if a "car" field already exists, its value is changed to "Suzuki Alto". Any other fields in the custom data objects remain unchanged.
|||newPassword||string||The new password to replace the old one. Use this parameter with password. When passing the securityQuestion or securityAnswer parameters the password parameter is required.|
|||password||string||The old password to be changed. Use this parameter with newPassword.|
A Preferences Object containing subscription data for this user. When manually passing consent information for a user using this method, you can change only the value of the isConsentGranted Boolean parameter and tags (only when accompanied by a status change of isConsentGranted).
Passing this as an array is not supported.
|||profile||Profile object||The user's profile information as described in the Profile object. You may add to the predefined Gigya fields your own custom profile fields.|
Sets the specified user's rba policy. Available properties include:
Code example to set a policy:
Code example to remove the policy:
For setting a site's RBA Policy, see Risk Based Authentication.
|||removeLoginEmails||string||A comma-separated list of emails to be removed from the user's login identifiers list.|
|||requirePasswordChange||Boolean||When set to true the server will require a password change on the next login.|
|||secretAnswer||string||A secret answer to the secret question that can be used for verification. Use this parameter with secretQuestion . Changing the secret answer will not work without providing the existing password ( password parameter). This field is hashed and can not be extracted.|
|||secretQuestion||string||A secret question that can be used for verification. Use this parameter with secretAnswer . Changing the secret question will not work without providing the existing password (password parameter).|
|||subscriptions||JSON object||A Subscriptions Object containing subscription data for this user. When manually passing subscription infromation for a user using this method, you can change only the value of the isSubscribed and tags parameters.|
|||username||string||The user's new username that can be used as a login identifier, if the site's Login Identifier Policy allow that.|
|||oldPassword||Boolean||Deprecated . Use the password parameter instead.|
Response Object Data Members
In case of a data validation errors (errorCode 400006), you will receive this field as an array of error objects. Each object represents a validation error regarding one of the following fields: username, password, secretQuestion, secretAnswer, email. For example: