This method retrieves extended information regarding a user.
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.
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.
|||includeAllIdentities||Boolean||This parameter's default value is false. If set to 'true' you will receive all the user's identities, including those with expired sessions. Each entry will have an attribute that will be 'true' when the session has expired for that provider (or is otherwise inactive) and 'false' if it is active.|
This parameter accepts a comma-separated list of additional data fields to retrieve. 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, likes, followersCount, followingCount, name, username, educationLevel, locale, verified, irank, timezone, and samlData.
Note: Before your application can retrieve Facebook data, the user must grant your application with access. Please make sure you have checked the check boxes that enable retrieving the relevant fields from Facebook in the Permissions page on Gigya's website. You may find more information in the Facebook Permissions section of our guide.
|||enabledProviders||string||A comma delimited list of providers from which to return user information in the response. |
If you do not set this parameter, by default the following providers are enabled: facebook, twitter, yahoo, linkedIn, messenger, google+, foursquare, vkontakte, renren, qq, sina, instagram, aol, blogger, wordpress.
In addition the following providers are supported and may be added explicitly: netlog, orangefrance, mixi, livedoor, paypal, paypaloauth, amazon, xing.
You may use the '*' sign as an indication to include all the default providers.
If you would like the API methods to apply only to Facebook and Twitter, define: enabledProviders="facebook,twitter".
Note: This method applies to only connected providers.
|||disabledProviders||string||A comma delimited list of providers from which not to return user information in the response. If you do not set this parameter, by default no provider is disabled (i.e. the method applies to all connected providers).|
For example, if you would like the method to apply to all providers except Google+ and Twitter, define: disabledProviders="googleplus, twitter".
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.
|user data||User object||Information about the user. See JSON example below for the user data representation. Only fields with data are returned. Note that unlike client-based calls, the identities field returns an array and the capabilities field a comma separated string.|
A field that does not contain data will not appear in the response.