You may need to have information about an Issue or end user redacted under the following circumstances:

  • An end user has sent sensitive data in a message to an Agent unknowingly.
  • An end user has attached or uploaded a file with sensitive data to an Issue.
  • An end user has invoked Article 17 of the GDPR, “Right to Be Forgotten”.

The following types of information can be redacted via a redaction request:

  • Username
  • Email
  • The content of messages sent by the Agent or end user
  • CSAT feedback
  • Attachments
  • Custom Issue Fields
  • Campaigns related data (user attributes)
  • Titles and user identifiers in Helpshift Analytics

Please note the following regarding our Issue redaction processes:

  • Archived Issues will be redacted along with Open and Closed Issues.
  • After Issue or user data has been redacted, all redacted Issues will look like this in your Dashboard:

To see what an Issue will look like to an end user after redaction, see What will my end users see after an Issue has been redacted?

There are two ways to submit a redaction request, as detailed below. Option 1 is recommended, as it streamlines the process, is easier for a larger amount of redaction requests, and has a faster completion time. Option 2 should be used only for small one-off requests, and is scheduled to be deprecated in mid-2019.

  1. Complete redaction requests using our REST APIs (recommended)
  2. Manually submit CSVs to Helpshift Support

1. Complete redaction requests using our REST APIs (recommended)

Helpshift provides a set of REST APIs that you can use to automatically create redaction requests to have personal support data removed per GDPR requirements. Redactions are processed on a weekly basis.

These redaction requests can be either ‘User’ or ‘Issue’ redactions, which indicates what type of content is to be redacted from our system (see the table below for details). Your organization will then use the REST /redaction API and provide a set of requests to Helpshift for processing. Once created, Helpshift will automatically schedule a periodic batch process that will perform the actual removal of that information. Your organization can periodically use the /redaction API to monitor the status of the current set of redaction requests.

To provide flexibility, user redactions can be identified via a variety of different methods, as defined in the table below.

Type What is redacted? How is the information identified? Creating a redaction request
User User redactions will redact a specific HS user object from Helpshift, along with all private data for the user, and all Issues associated with that user. HS user objects can found under the /users endpoint, or through the ‘reporter’ property on a specific Issue.

Note: Multiple user objects may exist for the same end user, since user objects are unique per application and / or per device. As such, you may need to create multiple requests if more than one user object is identified.

User redactions are created by indicating that the ”redaction_type’ is ‘user’, then providing one of the following identities:

– HS User ID: The unique ID used by Helpshift to track a user object that is exposed


– External User ID: If your organization has captured a unique user ID using the ‘loginWithIdentifier’ parameter, this ID can be used to identify the user to be redacted


– Email: If your organization has set an email when creating Issues, or uses email support, then email can be used


– Issue: A single Issue can be used to identify a user; when an Issue is used, the user that reported the Issue will be redacted along with all other Issues by that same user

Issue Issue redactions will remove private data from a specific Issue, and also remove the association with any user object. However, the user object and any other associated Issues will remain in Helpshift. This is identified via the Helpshift Issue ID. Issue redactions are created by indicating that the ”redaction_type’ is ‘Issue’, then providing the ID of the Issue.

Once your organization has a set of users or a set of Issues identified for redaction, you can use the REST APIs to create and monitor these redaction requests. (See our developer documentation on getting started to learn more about how to use the REST API).

PART 1: Creating Redaction Requests (POST /redaction)

API: POST /redaction

The POST /redaction API can be used to submit a set of redaction requests by passing in a set of redactions that are passed in through the ‘requests’ object that is an array of requests passed in through a JSON format as follows:

requests: [ {
redaction_type (string) = [‘issue’, ‘user’],
property (string) = [’email’, ‘issue_id’, ‘hs_user_id’, ‘external_user_id’],
value (string),
app_publish_id (string),
external_redaction_id (string, optional) } ]

The requests object contains the following properties:

Property Type Required? Description
redaction_type String Yes “user” or “issue” to indicate the type of redaction
property String Yes “user_id” OR “hs_user_id” OR “issue_id” OR “email” to indicate what identity will be provided

Note: For ‘issue’ reduction_type only – “issue_id” is allowed

value String Yes The actual identity (User ID, HS User ID, Issue ID or Email) used to identify what to be redacted
app_publish_id App ID Yes The app that the redaction will take place for – this must match the app for the user or Issue
external_redaction_id String No An optional external tracking ID that can be set when creating the redaction request


Sample CURL Request:

curl -X POST
-H “Authorization: Basic ########”
-H “Cache-Control: no-cache”
-H “Content-Type: multipart/form-data; boundary=—-WebKitFormBoundary7MA4YWxkTrZu0gW”
-F “requests=[ { “redaction_type”: “issue”%2C “property”: “issue_id”%2C “value”: “270”%2C “app_publish_id”: “ashbys_app_20160114162721083-1b1c89778dd4154″%2C “external_redaction_id”: “my_redactiondb_id_123″ } ]”


The following will be returned from the POST request:

Parameter Type Description
redaction_id ID A unique ID used to track the redaction request
success T/F Indication if the creation of the redaction request was a success
external_redaction_id ID The external ID given in the request for tracking
eta Date The estimated date when the job may complete
reason String If there is a failure to create a request, this is the reason why that request failed – user id / issue id is invalid / is already redacted / has existing redaction request / is part of existing user redaction request

Example Response:

PART 2: Confirming Redaction Status

API: GET /redaction/status

The GET /redaction/status API will return a set of existing redaction requests along with the current status of each request.


The GET /redaction/status API are used to identify specific redaction requests. At least one of the following filters are required.

Filter Use
/redactions/status?external_redaction_id=value Uses an external redaction ID to filter redaction requests
/redactions/status?redaction_id=value Find a specific redaction request based on redaction ID
/redactions/status?issue_id=value Find redaction request based on issue ID
/redactions/status?email=value Find redaction requests created for a specific email address
/redactions/status?external_user_id=value Find redaction requests created based on the external user ID
/redactions/status?hs_user_id=value Find redaction requests created based on the Helpshift user ID

Additional Parameters:


  • page(Optional)


    = Returns a specific page when handling large lists


The GET request will return a JSON response that includes the set of redaction request objects in the following format.

“redaction_id”: “string”,
“status”: “created”,
“eta”: “string”,
“reason”: “string”,
“request”: {
“redaction_type”: “issue”,
“property”: “email”,
“value”: “string”,
“app_publish_id”: “string”,
“external_redaction_id”: “string”

Request object details:

Properties Type Description
redaction_id String HS returned ID of the redaction request
eta String expected date of redaction
status String created: The export or remove job is started
done: The export or remove job is complete
not_found: There is no export or remove job with the given job id
running: The export or remove job is in progress
waiting: The export or remove job has not started
reason String Reason for any failure to process a request
request Object Original redaction request object passed in through POST


Using the GET /redactions/status?(filter) to list redactions


curl -X GET -H “Authorization: Basic #############” -H “Cache-Control: no-cache” “”

Example Response:

2. Manually submit CSVs to Helpshift Support

Please note: this option should be reserved for small, one-off redaction requests, and is scheduled to be deprecated in mid-2019.

To submit a manual request for Issue redaction to our support team, complete the following steps:

1. Create a CSV file and name it {YourDomain}_RedactionRequest_AdminName_DDMMYY (date, month, year).

2. Within that CSV file, copy-paste the following information about the Issue:

    • Column A: your domain name (exact match as it appears in your Dashboard URL)
    • Column B: the app publish ID, which can be found on your Settings > App Settings page (per the screenshot below)

  • Column C: the Issue ID number (enter numbers only)
  • Column D: the end user’s email address (only required for user redaction requests; optional for Issue redaction requests)
  • Column E: the type of redaction, either ‘I’ for an entire Issue or ‘U’ for an end user
    • Please note: ‘U’ is meant for end users who are invoking their “Right to be Forgotten” per GDPR legislation.

3. Once you’ve created this spreadsheet, notify the Admin of your team that you have a redaction request.

4. As the Admin, you should then review the redaction nominations and the CSV filename to ensure everything is correct. Once you’ve done so, send an email to with the subject line ‘Redaction Request: {DOMAIN}’ and attach the .CSV file with the file name as: {DOMAIN}_RedactionRequest_AdminName_DDMMYY.

Our support team will follow up with an email confirmation once the submitted file has been processed for redaction. We will process all redaction requests within 28 days from the time of submission.