The accounts.verifyLogin API checks user profile information against the required schema fields and site policies to ensure that all the necessary data is in place. In site groups, this is done across multiple domains. If validation passes, the user's account information is returned. If not, an error is returned.
Note: Depending on your site package, this method may not return the user's account information, but will return an OK response instead.
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.
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.
|||uid||string||The unique user ID. This user ID should be used for login verification. See User.UID for more information.|
|||extraProfileFields||string||This parameter accepts a comma-separated list of additional social profile fields to retrieve, and return in the response. The current valid values are: languages, address, phones, education, honors, publications, patents, certifications, professionalHeadline, bio, industry, specialties, work, skills, religion, politicalView, interestedIn, relationshipStatus, hometown, favorites, followersCount, followingCount, username, locale, verified, timezone, likes and samlData.|
|||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, preferences, subscriptions, groups and irank. The default is profile so if this parameter is not used, the response will return the Profile object.|
|||UID||string||The unique user ID. This user ID should be used for login verification. See User.UID for more information.|
|||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, preferences, subscriptions, groups and |
id_token. The default is profile so if this parameter is not used, the response will return the Profile object.
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:
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 registration (error code 206001) - returned when the registration process has not been finalized, or the schema defines fields as required and one or more of these fields were not passed in the registration proccess. 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.
- 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.
- Login Failed Captcha Required (error code 401020) - returned when login is attempted and the CAPTCHA threshold has been reached. The CAPTCHA threshold is set in the site Policies (security .captcha.failedLoginThreshold policy).
- Login Failed Wrong Captcha (error code 401021) - returned when login is attempted and the CAPTCHA threshold has been reached and the provided CAPTCHA text is wrong. The CAPTCHA threshold is set in the site Policies (security .captcha.failedLoginThreshold policy).
- Old password used (error code 401030) - returned when login is attempted with a password that doesn't match the current password but does match the previous one. The server will return this error with the message saying that "the password was modified on" the date when the current password was set.
- Account disabled (error code 403041) - returned when a user tries to login and the account is disabled.
- 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.
- Login identifier exists (error code 403043) - returned when email is defined as the loginIdentifier 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).
- Under User (error code 403044) - returned when a user under the age of 13 tries to login.
- Pending password change (error code 403100) - returned when login is attempted and the password change interval has passed since the last password change. The interval is set in the security.passwordChangeInterval policy.
- Account Pending TFA Verification/Registration (error codes 403101/403102) - returned w hen 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.
- Account Temporarily Locked Out (error code 403120) - returned when login is attempted and the account is locked out or the originating IP is locked out. This occurs after a set number of failed login attempts. The number is set in the site Policies - security .accountLockout.failedLoginThreshold policy and security.ipLockout.hourlyFailedLoginThreshold policy.