This method completes on-site user registration. For registration through a social network, see accounts.socialLogin.
On-site registration requires three API calls:
- accounts.finalizeRegistration (This method is not required if the finalizeRegistration parameter was set to 'true' in accounts.register).
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.
|||regToken||string||The regToken returned from accounts.initRegistration. If there were errors incurred using accounts.register or from accounts.login, this is the new regToken returned from those calls (i.e., if the user tried to sign in without completing registration or there were missing required fields). Note that the regToken you receive from Gigya is only valid for 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, irank, subscriptions, rba. If none these parameter are provided, none of the aforementioned properties are returned in the response; only the profile and data objects are returned by default.|
|||allowAccountsLinking||Boolean||Default is false. 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.
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 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||An object containg session information. The content of this object depends on the targetEnv parameter passed in the accounts.register method.|
By default, if the targetEnv parameter is not set (your client environment is web), the sessionInfo object contains the the following string fields: cookieName and cookieValue.
Please create a session cookie with the name and value specified by these fields.
Alternatively, if the targetEnv parameter is set to "mobile" (your client runs on a mobile), the sessionInfo object contains the the following string fields: sessionToken and sessionSecret. Please send these fields to your mobile client. On your client side, call GSAPI.setSession (using the Mobile SDK) to save them on the app's storage.
|regToken||string||A ticket that is used to complete a registration process. A new 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.|
|newUser||Boolean||Indicates whether a new user was created in this call.|
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.
- 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.