This method retrieves user account data.
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.
|||UID||string||The unique ID of the user for which to retrieve data. Use either this parameter or regToken .|
If you call this method through an external OAuth2 SDK, then the UID may be passed implicitly within the access_token.
|||regToken||string||The regToken returned from accounts.initRegistration, accounts.register or accounts.login API calls when the registration process has not been finalized. Please note that the regToken you receive from Gigya is valid for only one hour.|
|Note: You are required to pass only one of the parameters - either UID or regToken.|
A comma-separated list of fields to include in the response. The possible values are: identities-active , identities-all , identities-global , loginIDs , emails, profile, data, password, isLockedOut, lastLoginLocation, regSource, irank, rba, subscriptions, userInfo, preferences. The default value is "profile , data,subscriptions" so if this parameter is not used, the response will return the Profile and data objects, and subscriptions, if any are associated with the user.
Note: Make sure the parameter does not contain spaces between the values.
|||extraProfileFields||string||This parameter accepts a comma-separated list of additional social profile fields to retrieve. The current valid values are: languages, address, phones, education, educationLevel, honors, publications, patents, certifications, professionalHeadline, bio, industry, specialties, work, skills, religion, politicalView, interestedIn, relationshipStatus, hometown, favorites, followersCount, followingCount, username, name, locale, verified, timezone, likes, samlData.|
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.
A field that does not contain data will not appear in the response.