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.
This API is used to obtain an id_token containing an existing user's data in JWS format . This id_token can then be transmitted between servers, enabling a partner to share a user's data among multiple sites/API keys. You can validate the JWT using the originating site's public key returned from accounts.getJWTPublicKey.
accounts.getJWT requires an app or user key with full data access when being used via REST, see Data Field Access for more information.
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.
|||apiKey||string||The API key of the target site containing the existing user's data.|
The partner secret or both an application/user key and it's corresponding secret.
*When passing an application/user key secret, you must also pass a userKey parameter that the secret is associated to.
|||targetUID||string||The UID of the user whose data is being requested. Must be a user for the site of the associated apiKey (above).|
||userKey*||string||The userKey associated with the secret, if not using a partner secret.|
||fields||string, comma delimited|
Any existing profile and/or data fields in the target site's database you want to explicitly return in the JWT for this targetUID.
When requesting profile fields, it is not necessary to prepend 'profile.' (e.g., profile.firstName can be passed as firstName).
||expiration||integer||The TTL of the returned JWT, in seconds. If this parameter is not passed, the default is 300.|
||Determines the format of the response. The options are:
- json (default)
- 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 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.
|id_token||JSON Web Token||The returned JWT containing the user's data.|
|ignoredFields||string||If any fields that were passed do not exist for the requested apiKey, they will be ignored and listed here.|
||The HTTP response code of the operation. Code '200' indicates success.
||The result code of the operation. Code '0' indicates success, any other number indicates failure. For a complete list of error codes, see the Error Codes table.
||A brief explanation of the status code.
||A short textual description of an error, associated with the errorCode, for logging purposes. This field will appear in the response only in case of an error.
||This field will appear in the response only in case of an error and will contain the exception info, if available.
||The full name of the event that triggered the response. This is an internally used parameter that is not always returned and should not be relied upon by your implementation.
||Unique identifier of the transaction, for debugging purposes.
||The time of the response represented in ISO 8601 format, i.e., yyyy-mm-dd-Thh:MM:ss.SSSZ or
A field that does not contain data will not appear in the response.
Whenever relying on the contents of the response from accounts.getJWT, e.g., before adding the user's data to a new database, you should validate that the content has not been manipulated in transit. You can do that by validating the signature against the host site's public key. Please see How To Validate A Gigya id_token for additional information.