Gigya Job Openings

comments.deleteComment REST

Skip to end of metadata
Go to start of metadata

Description

This method deletes a specified comment, allowing moderators to delete any comments and users to delete their own comments. 

If a moderator deletes a comment, the points that were awarded for that comment via Gamification will also be removed.

Note: Only logged-in users can delete their comments.

 

Note: If the request includes the UID parameter, only comments of that user may be deleted.

 

Request URL


Where <Data_Center> is:
  • us1.gigya.com - For the US data center.
  • eu1.gigya.com - For the European data center.
  • au1.gigya.com - For the Australian data center.
  • ru1.gigya.com - For the Russian data center.
  • cn1.gigya-api.cn - For the Chinese data center.

If you are not sure of your site's data center, see Finding Your Data Center.

Parameters

RequiredNameTypeDescription
 categoryIDstringThe identifier of the comments category to delete.
streamIDstringThe identifier of the comments stream to delete.
commentIDstringThe identifier of the comment to delete.
UIDstring

The unique ID of a logged-in user, whose comment is to be deleted, when a user is deleting their own comment. This is the UID you receive from Gigya after a successful login of this user.

An admin can additionally use UID as a validation tool to ensure the comment being deleted is the correct one. If the UID is supplied, it will verify the specified comment is connected to the specified UID, otherwise, a No_user_permission error is returned.

noteobjectThe note is a custom object, which may include additional information about the reason for the deletion and who performed it.

Authorization Parameters

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:

  • accounts.login
  • socialize.login
  • accounts.notifyLogin
  • socialize.notifyLogin
  • accounts.finalizeRegistration
  • accounts.linkAccounts

Please refer to the Authorization Parameters section for details. 

 

Response Data

FieldTypeDescription
 
errorCode integer 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.
errorMessage string 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.
errorDetails string This field will appear in the response only in case of an error and will contain the exception info, if available.
fullEventName string 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.
callId string Unique identifier of the transaction, for debugging purposes.
time string The time of the response represented in ISO 8601 format, i.e., yyyy-mm-dd-Thh:MM:ss.SSSZ or
statusCode integer The HTTP response code of the operation. Code '200' indicates success.
This property is deprecated and only returned for backward compatibility.
statusReason string A brief explanation of the status code.
This property is deprecated and only returned for backward compatibility.

 

A field that does not contain data will not appear in the response.

 

Sample Requests

 

Response Example

{
        "statusCode": 200,
        "errorCode": 0,
        "statusReason": "OK",
        "callId": "ddb3f8e144c84cb5b1bc5f010bddab2b",
        "time": "2015-03-22T11:42:25.943Z"
}