This method merges the account identified by the provided UID with the account identified by the provided login credentials (loginID + password). The method first validates the login credentials, then merges the data and social connections from both accounts into one account.
us1.gigya.com- For the US data center.
eu1- For the European data center.
au1- For the Australian data center.
ru1- For the Russian data center.
cn1- For the Chinese data center.
If you are not sure of your site's data center, see Finding Your Data Center.
This method requires HTTPS.
|||UID||string||The unique ID of a logged-in user. Use either this parameter or regToken.|
|||regToken||string||A token that is used to complete the registration process. Use either this parameter or UID. The regToken is returned from the accounts.login, accounts.socialLogin, or accounts.initRegistration API calls when the registration process has not been finalized.|
|||loginID||string||The existing account's login identifier. Can be a simple username or an email address.|
|||password||string||The existing account's password.|
|||include||string||A comma-separated list of fields to include in the response. The possible values are: identities-active, identities-all, loginIDs, emails, profile, data, and |
id_token. The default is profile and data so if this parameter is not used, the response will return the Profile and data objects.
|||targetEnv||string||This parameter defines your client side environment, which in return determines the server response data fields. The default value of this parameter is "browser", which means that by default you receive cookie-related data in the response.|
If your client runs on a mobile:
If you are calling this method using a Mobile SDK since version 2.15.6, this parameter is automatically set to "mobile" (there is no need to set it manually). In any other case, you should set this parameter to be "mobile".
As a result of setting the parameter to "mobile" the server response data fields will include: sessionToken and sessionSecret (instead of cookie related data). In such case, you should send the sessionToken and sessionSecret to your mobile client. On your client side, call GSAPI.setSession (using the Mobile SDK) to save them in the app's storage.
Each REST API request must contain identification and authorization parameters.
Some REST APIs may function without these authorization parameters, however, when that occurs, these calls are treated as client-side calls and all client-side rate limits will apply. In order to not reach client-side IP rate limits that may impact your implementation when using server-to-server REST calls, it is Recommended Best Practice to always sign the request or use a secret. A non-exhaustive list of REST APIs that this may apply to are as follows:
Please refer to the Authorization Parameters section for details.
|sessionInfo||JSON object||Can be the combination of cookieName (string) + cookieValue (string) or sessionToken (string) + sessionSecret (string), depending on targetEnv. If targetEnv is "browser", the response is cookieName and cookieValue, and if targetEnv is "mobile", the response is sessionToken and sessionSecret.|
|regToken||string||A ticket that is used to complete a registration process. The regToken is returned when there is a pending registration error, which occurs when the user did not complete the registration process, or there are missing fields in the user profile data that were defined as "required" in the Schema.|
|unverifiedEmails||array||One or more unverified emails, in case there is a pending verification error.|
A field that does not contain data will not appear in the response.
Gigya defines specific error codes and messages that are used with the Accounts API. These errors are returned with the APIs, indicating that some information is incorrect or missing.
This section describes the errors that are related to this API, the reasons for each error, and the expected next step.
- Account pending verification (error code 206002) - returned when the account has already been verified, and a user tries to log in with a loginID (usually an email address) that we have not yet verified that actually belongs to this person. When the accountOptions policy states that verifyEmail is true, the account must be validated by using the available email addresses. When the policy states that allowUnverifiedLogin is "false", users are not allowed to login before they have verified their emails. So, in this case, when a user tries to login, and his account has not been verified yet, and verifyEmail is true in the policy and allowUnverifiedLogin is false in the policy, the "Account pending verification" error is returned. The expected next step is: call accounts.resendVerificationCode to resend a validation email to the unverified addresses associated with the account. The email format is according to the templates defined in the policy.
- Invalid loginID (error code 403042) - returned when a user tries to perform an action that requires a login identifier (username or email) and the login ID doesn't exist in our accounts database. It is also returned if the password that is passed in the API is incorrect.