Disconnects the current user from one or all of the connected providers. Disconnection from a provider means that the session with the provider closes. Removing connection also disassociates (unlinks) the social identity from the user, unless this is the user's only login identity. For the following providers the removeConnection will also logout the user from the social network: Facebook, Yahoo, Google, and LinkedIn.
This operation currently supported by the following providers: Amazon, AOL, Blogger, Facebook, FourSquare, GooglePlus, Instagram, Kakao, LINE, LinkedIn, Livedoor, Messenger, mixi, Naver, Netlog, Odnoklassniki, Orange France, PayPalOAuth, Tencent QQ, Renren, Sina Weibo, Spiceworks, Twitter, VKontakte, WeChat, WordPress, Xing, Yahoo, Yahoo Japan.
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.
||The unique ID of the user with which this method call is associated (i.e., the logged-in user whom is performing the action on the client-side and triggering the REST call). This is the UID you receive from Gigya after a successful login of this user. See User.UID for more information.
Note: If you are using account linking then the UID would be your site user ID. To learn more about Social Login with account linking (best practice), please refer to the Social Login Implementation guide.
- The UID parameter is required when you call this method through one of the following interfaces:
or if you are using the REST API directly with Gigya's proprietary authorization method.
- The UID parameter is not required when you call this method through one of the following interfaces: Android SDK, iOS SDK or if you are using an external OAuth2 SDK.
||provider||string||The provider to disconnect from. The optional values for this parameter are: 'facebook', 'twitter', 'yahoo', 'microsoft', 'linkedin', 'qq', 'renren', 'sina' (Note: messenger has been replaced by microsoft, however, for backward compatibility, either can be used), 'renren', 'vkontakte', 'mixi'. If this parameter is not set, then the user will be disconnected from all the providers.|
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.
||removeLoginID||Boolean||Indicates whether the server should remove the login ID that is associated with the removed social network identity. This can be done as long as the following conditions are met:|
- The login ID is not associated with any other identity (site or social)
- After removing the login ID there is still another way to login to the account, i.e. either there is another social identity connected to the account or there is another login ID and password pair.
If these conditions are not met, for example, if the social identity being removed is the last social identity and the associated login ID is the last login ID. In this case the operation fails without removing anything. The default value is "false".
||lastIdentityHandling||string||Determines how to handle attempts to remove the last login identity. May be either "soft" or "fail":|
- "soft" - Indicates that Gigya will remove all the stored information related to the connection, except for the mapping between this user account and the social user. This way Gigya deletes all the information about the user but the account remains accessible if the user ever tries to login again using the same social identity. Completely deleting any association with the last connected identity may be achieved by deleting the account using socialize.deleteAccount.
- "fail" - Indicates that the last login identity cannot be removed by Gigya, an error indicating this will be returned.
|| || || |
||Determines the format of the response. This parameter is required when using the REST API directly, and irrelevant when using one of our SDKs. The options are:
- jsonp - if the format is jsonp then you are required to define a callback method (see parameter below).
- xml (default) - Deprecated. We do not support XML format anymore, but it is the default due to backwards compatibility. Please set the format parameter to either json or jsonp.
||This parameter is relevant only when the format parameter is set to jsonp (see above). In such case this parameter should define the name of the callback method to be called in the response, along with the jsonp response data. |
||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 occurs.
Each REST API request must contain identification and authorization parameters.
Please refer to the Authorization Parameters section for details.
||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.