This method uploads a user's profile photo to Gigya's server.
By default the uploaded photo is treated as a temporary photo. You can decide whether to publish the photo into the user's account, using the publish parameter (see below), or you can publish later using the accounts.publishProfilePhoto API method.
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 to which to associate the uploaded photo.|
|||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.|
|* You are required to pass only one of the parameters either UID or regToken.|
|||photoBytes||string||A BASE64 encoded string representation of the photo bytes. The size limit of the photo is 6MB, and the supported image types are png, jpeg, and gif.|
|||publish||Boolean||Indicates whether to publish this photo to the user's profile or treat it as a temporary photo. The default value is 'false', i.e. the photo is temporary. You can later publish a temporary photo using the accounts.publishProfilePhoto API method. If published, the photo is saved in the photoURL field of the user's Profile, in addition the photo is trimmed to the size defined in the site's Policies (64X64 by default) and saved in the thumbnailURL field.|
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.
A field that does not contain data will not appear in the response.