This method completes on-site user registration. For registration through a social network, see accounts.socialLogin.
On-site registration requires three API calls:
This method is not required if the finalizeRegistration parameter was set to true in accounts.register.
The following table lists the available parameters:
|||regToken||string||The regToken returned from accounts.initRegistration and accounts.register or from accounts.login if the user tried to sign in without completing the registration. Please note that the regToken you receive from Gigya is valid for only one hour.|
|||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 irank. If this parameter is not used, the response will return only the User object.|
|||allowAccountsLinking||Boolean||'false' by default. If 'true', the server allows regTokens generated by account linking.|
|||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.
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 relate 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.
- Account Pending TFA Verification/Registration (error codes 403101/403102) - returned when a user calls this method and the policy (in the site Policies) requires 2-factor authentication, and the device is not in the verified device list for the account.