Note: This methodis treated as a client-side call, so even if you pass your secret key to the API call, you still will not be able to set profile or data fields that have a writeAccess mode of 'serverOnly'. In this instance, if you are registering an account that has fields with 'serverOnly' writeAccess, then make the call to accounts.register without these fields in the profile/data object, and then take the UID from the register response, and pass it to accounts.setAccountInfo, which will be treated as a server-side call if you pass a secret/signature and the UID (not the regToken).
The above information is not applicable for customers already participating in the Gigya Early Adopters Program, where server-side calls are always recognized as server-to-server.
Note: If you plan on integrating Gigya's Accounts API, we highly recommend reading the Registration-as-a-Service Guide. Registration-as-a-Service (RaaS) is a premium platform that requires separate activation. If RaaS is not part of your site package, please contact Gigya by filling in a support form through the Console. You can access the support page by clicking Support on the upper menu after logging into the Gigya Console.
*You are required to pass eitherusernameor email, depending on the specification of the site's Login Identifier policy. If the emailVerification policy is enabled, an email is always required during registration, regardless of the defined login identifier.
The user's password. Gigya validates that the password meets the complexity requirements defined in the site's Password Strength policy.
The user's profile information. The object may include site's custom fields in addition to reserved field names (as defined in the Profileobject). Fields that are defined as required in the Schema, are required by this method. If not passed, the method will return a "pending registration" error and a new regToken.
The CAPTCHA text typed by the user.This parameter is required if specified so in the site's CAPTCHA policy.
The CAPTCHA challenge. This parameter is required if specified so in the site's CAPTCHA policy.
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.
Custom data. The purpose of this object is storing any custom data associated to the user, but which is not part of the Profile object. Gigya validates that the data fields meet the requirements that are defined in the Schema.
If set to 'true', this API call will also finalize the registration process for the user, and the user will appear as a 'New registered user' in the user reports. If there are missing fields, the registration will remain pending. The default value is 'false'.
A Preferences Object containing consent data for this user.
The secret question that can be used for verification. This parameter is required if specified so in the site's requireSecurityQuestionPolicy.
The answer to the secret question. This parameter is required if specified so in the site's requireSecurityQuestionPolicy.
The language to use in error messages and validation emails. See also Email Templates. The language specified here is stored in the locale field of the site identity. If in the emailVerification policy the emailTemplates include a template in the specified language, the verification email sent to the user will be in this language. The same goes for the passwordReset policy.
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.
A comma-separated list of fields to include in the response. The possible values are: identities-active,identities-all, loginIDs, emails, profile, data, password, lastLoginLocationand irank. The default is profile, so if this parameter is not used the response will return only the Profile object.
This parameter defines the time in seconds that Gigya should keep the login session valid for the user. To end the session when the browser closes, please assign the value '0'. If this parameter is not specified, the session is valid forever. See Managing Session Expiration for additional information. Note: The value of this parameter overrides the value of the identical parameter in the Global Configuration.
You may specify the UID to use with this account; if not specified, it is auto-generated. Note: The parameter accepts up to 252 ASCII characters (unicode is not supported).
Records the source of the registration. The default value is the URL of the current page but it can be any string value. regSource is stored in the account and can be used by verification emails to determine which page should be opened (see accounts.set Policies). Can also be set via the Global Conf object.
Determines the format of the response. The options are:
jsonp - if the format is jsonp then you are required to define a callback method (see parameter below).
This parameter is required only when the format parameter is set to jsonp (see above). In such cases this parameter should define the name of the callback method to be called in the response, along with the jsonp response data.
This parameter may be used to pass data through the current method and return it, unchanged, within the response.
This parameter may be used in order to suppress the showing of screen-sets as a result of API calls. Default is false.
The default value of this parameter is false, which means that the HTTP status code in Gigya's response is always 200 (OK), even if an error occurs. The error code and message is given within the response data (see below). If this parameter is set to true, the HTTP status code in Gigya's response would reflect an error, if one occurred.
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:
An object containg session information. The content of this object depends on the targetEnv parameter (see above). 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.
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. The regToken is valid for one hour from the moment it is returned.
One or more unverified emails, in case there is a pending verification error.
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 required fields: username, password, secretQuestion, secretAnswer, email. For example:
Indicates whether a new user was created in this call.
The unique user ID. This user ID should be used for login verification. See User.UID for more information.
The signature that should be used for login verification. See User.UID for more information.
The GMT time of the response in UNIX time format, i.e., the number of seconds since Jan. 1st 1970. The timestamp should be used for login verification. See User.UID for more information.
The UTC time the account was created in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The UTC time the account was created in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
Custom data. Any data that you want to store regarding the user that isn't part of the Profile object.
The email addresses belonging to the user. This includes the following fields:
verified - an array of strings representing the user's verified email addresses
unverified - an array of strings representing the user's unverified email addresses.
Note: emails must be specified explicitly in the include parameter in order to be included in the response.
When using CIAM for B2B, this is where the user's Organization Management data is stored. For a detailed description of this field, see the Groups object documentation.
An array of Identity Objects, each object represents a user's social identity. Each Identity Object contains imported data from a social network that the user has connected to. Note: You must explicitly specify identities within the include parameter for them to be included in the response: identities-active , identities-all, or identities-global to return only active identities, all identities of a site, or all identities of a site group, respectively.
Be advised that if a user registers to your site using a Social Identity, then goes through the Forgot Password flow, a Site Login is added to their account, however, a Site Identity is not. A Site Identity can only be created when accounts.setAccountInfo is called on the user's account.
Influencer rank of the user. This property is deprecated and will always return 0.
Indicates whether the account is active. The account is active once the user creates it even without finalizing it. The account can be deactivated, but it will still be registered if the registration process has been finalized. If isActive==false the user cannot log in, however any currently active sessions remain valid.
Indicates whether the account is currently locked out. This parameter is not included in the response by default, and is not returned at all from accounts.search. If you wish to include it in a response, specify it as a value of the include parameter.
Indicates whether the user is registered. The user is registered once his registration has been finalized.
Indicates whether the account email is verified.
The time of the last login of the user in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The user's last login location. This includes the following fields:
country - a string representing the two-character country code.
state - a string representing the state, where available.
city - a string representing the city name.
coordinates - an object containing:
lat - a double representing the latitude of the center of the city.
lon - a double representing the longitude of the center of the city.
The UTC time of the last login of the user in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
The UTC time when user profile, preferences, or subscriptions data was last updated (either full or partial update) in ISO 8601 format, e.g., "2017-07-16T19:20:30Z".
The UTC time when the last update of the object occurred (either full or partial update) in Unix time including milliseconds, based on when the 'lastUpdated', 'Report AccountsFirstLogin' or 'AccountsReturnedLogin' events are fired.
The user's login identifiers. This includes the following fields:
username - a string representing the username
emails - an array of strings representing email addresses
unverifiedEmails - an array of strings representing email addresses that were not validated
Note: loginIDs must be specified explicitly in the include parameter in order to be included in the response.
The name of the provider that the user used in order to login.
The UTC time when the oldest data of the object was refreshed in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The UTC time when the oldest data of the object was refreshed in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
The user's Site account password details. Includes the following:
hash - the hashed password
hashSettings - object includes:
algorithm - Represents the hash algorithm used to encrypt the password.
rounds - Represents the number of iterations to perform the hashing.
salt - Represents the BASE64 encoded value of the salt.
format - Represents the template for merging clear-text passwords. This is only returned if the pwHashFormat parameter was set during account import and until the user's first login to Gigya (when the user's password is rehashed per the site's settings). See the RaaS Import Guide for additional information.
This property is deprecated in server to server REST calls! The signature that should be used for login verification. See User.UID for more information.
This property is deprecated in server to server REST calls! The GMT time of the response in UNIX time format, i.e., the number of seconds since Jan. 1st 1970. The timestamp should be used for login verification. See User.UID for more information.
The user's profile information as described in the object. The profile is returned in the response by default, but if the include parameter is used to specify other fields that should be provided in the response, the profile must also be specified explicitly in the include parameter.
The current RBA Policy defined for the specified user. Properties include:
riskPolicy - Determines the rule set from the defined rulesSets configured in accounts.rba.setPolicy or one of the default policies.
riskPolicyLocked - Determines whether the user can change their own riskPolicy. If true, only an admin can change the user's riskPolicy.
The UTC time when the isRegistered parameter was set to true in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The GMT time when the isRegistered parameter was set to true in UNIX time format, including milliseconds.
A string representing the source of the registration. Can be used to set varying destination pages in accounts.setPolicies.
A comma-separated list of the names of the providers to which the user is connected/logged in.
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 registration (error code 206001) - returned when you call a method that performs social login, such as this method, and the registration process has not been finalized, or the schema defines fields as required and one or more of these fields are missing from the user Profile or data. The expected next step is: if the schema defines fields that are required and one or more of these fields are missing from the user profile or data, call accounts.setAccountInfo. If the registration process has not been finalized, call accounts.finalizeRegistration.
CAPTCHA verification failed (error code 400021) - returned when the registration policy states that requireCaptcha is "true", and the CAPTCHA verification fails when a user tries to register.
Login identifier exists (error code 403043) - returned when email is defined as theloginIdentifier in the accountOptions policy, and the email address received from the provider exists in the system but is associated with a different user. The expected next step: call accounts.linkAccounts to merge between the account identified by the provided UID and the account identified by the provided login credentials (loginID + password).
Validation errors - the validationErrors object is an array of validation errors; each validation error is made up of an errorCode, a message, and a fieldName. The errorCode and message specify what error occurred and the fieldName specifies which field had a validation error. When an invalid field type is used, i.e. a string instead of an integer, or if a wrong format is used, i.e. an email address that is not in a correct format, an "Invalid parameter value" error is returned (error code 400006). A validation error is returned whenever there is a data validation error regarding one of the following required fields: username, password, securityQuestion, secretAnswer, email. The expected next step is: call the API method again with the missing info.
This is not an exhaustive list of possible errors. These are specifically errors that may be encountered when using a custom implementation which require additional action to complete the registration of the user within the current context (to replace the built in logic of Screen-Sets). Additional information about specific recoverable Accounts errors can be found at Accounts API Error Codes and Messages.