Entry Deletion API Documentation

Last updated: September 16, 2026

Overview

The Entry Deletion API permanently deletes matching feedback Entries from one Unwrap view.

Entries can be selected using either:

  • A custom field, or segment, such as member_account_ID. These are called segment value deletes.

  • A primary identifier from a supported integration configured in Unwrap, such as Zendesk Ticket ID. These are called provider entry ID deletes.

Deletion is asynchronous. Unwrap first resolves the matching Entries and reports the match count. The caller must then confirm the operation before deletion begins.

Deletion does not prevent the source integration from importing the data again later. For example, if you delete a support case that still exists upstream in your ticketing platform, Unwrap's ingestion systems may re-ingest this case. You should first delete the case in the source system to ensure persistent removal in Unwrap.

Endpoint

Send GraphQL requests using POST to: https://data.api.production.unwrap.ai

Using the following headers:

Authorization: Bearer <unwrap_api_token>
Content-Type: application/json

Authentication

This API requires an Unwrap API token.

The API token is tied to the user who created it and can delete Entries only from teams where that user has sufficient access. If rejected as unauthorized, contact Unwrap Support.

The same API token must be used to request, view, and confirm a deletion operation. An operation requested by a different API token is not returned.

For more information, please see 📄 Getting Started.

Requesting Deletion by Segment Value

To request deletion using a configured segment value, use the following mutation:

mutation DeleteEntries($input: CustomerEntryDeletionRequestInput!) {
  requestEntryDeletion(input: $input) {
    operation {
      id
      requestId
      state
      matchedEntries
      deletedEntries
      percentComplete
      estimatedCompletion
      createdAt
      startedAt
      completedAt
      error {
        code
        message
        retryable
        supportReference
      }
    }
    error {
      code
      message
      retryable
      retryAfterSeconds
      supportReference
    }
  }
}

Example Requests

{
  "input": {
    "teamId": 123,
    "requestId": "deletion-4d7819a0-0899-4f70-bbf5-d5ba772a3499",
    "identifierType": "SEGMENT_VALUE",
    "segmentName": "member_account_ID",
    "identifierValue": "account-123"
  }
}

Replace teamId, requestId, segmentName, and identifierValue with values for your request.

segmentName must be nonblank, no more than 255 characters, and exactly identify one segment configured for the requested team. identifierValue must be nonblank and no more than 255 characters. Leading and trailing whitespace is ignored for both values. Segment value matching is case-sensitive.

Response

An accepted request returns an operation. Its initial state is normally RESOLVING, although QUEUED may appear briefly.

If Unwrap reserves the operation but cannot immediately initiate the deletion, the response can contain both a QUEUED operation and a TEMPORARY_UNAVAILABLE error. Retry with the same requestId; this returns or resumes the existing operation rather than creating another one.

The operation moves to AWAITING_CONFIRMATION after Unwrap resolves the match count. This also happens when matchedEntries is 0.

Requesting Deletion by Provider Entry ID

To request deletion using a provider entry ID, use the following mutation:

mutation DeleteProviderEntry($input: CustomerEntryDeletionRequestInput!) {
  requestEntryDeletion(input: $input) {
    operation {
      id
      requestId
      state
      matchedEntries
      deletedEntries
      percentComplete
      estimatedCompletion
      createdAt
      startedAt
      completedAt
      error {
        code
        message
        retryable
        supportReference
      }
    }
    error {
      code
      message
      retryable
      retryAfterSeconds
      supportReference
    }
  }
}

Example Requests

{
  "input": {
    "teamId": 123,
    "requestId": "deletion-f788e273-ff40-427f-b17d-31e66082b48e",
    "identifierType": "PROVIDER_ENTRY_ID",
    "identifierValue": "123456789",
    "feedbackIntegrationIds": [456]
  }
}
```json

Replace teamId, requestId, identifierValue, and feedbackIntegrationIds with values for your request.

feedbackIntegrationIds must contain at least one positive integration ID. Every supplied integration must belong to the requested team. Matching is restricted to those integrations.

identifierValue must be nonblank and no more than 255 characters.

Response

The response follows the same asynchronous resolution and confirmation process as segment-value deletion.

Checking Deletion Progress

Use the operation ID returned by requestEntryDeletion:

query DeletionStatus($teamId: Int!, $operationId: Int!) {
  entryDeletionOperation(teamId: $teamId, operationId: $operationId) {
    id
    requestId
    state
    matchedEntries
    deletedEntries
    percentComplete
    estimatedCompletion
    createdAt
    startedAt
    completedAt
    error {
      code
      message
      retryable
      supportReference
    }
  }
}

Example Request

{
  "teamId": 123,
  "operationId": 456
}

Response

entryDeletionOperation returns null when the operation does not exist for the supplied team or was created using a different API token.

estimatedCompletion, createdAt, startedAt, and completedAt are Unix timestamps in milliseconds. Nullable timestamp fields return null when no value is available.

Poll until the operation reaches AWAITING_CONFIRMATION or a terminal state.

Confirming a Deletion

After reviewing matchedEntries, confirm the operation using:

mutation ConfirmDeletion($teamId: Int!, $operationId: Int!) {
  confirmEntryDeletion(teamId: $teamId, operationId: $operationId) {
    operation {
      id
      state
      matchedEntries
      deletedEntries
      percentComplete
    }
    error {
      code
      message
      retryable
      supportReference
    }
  }
}

Example Variables

{
  "teamId": 123,
  "operationId": 456
}

Response

Confirmation signals the running deletion workflow asynchronously. The confirmation response can still show AWAITING_CONFIRMATION. Continue polling entryDeletionOperation until it reaches a terminal state.

Confirmation returns INVALID_STATE unless the operation is currently awaiting confirmation.

Deletion States

- QUEUED: The request was accepted but resolution has not started.

- RESOLVING: Unwrap is finding matching Entries.

- AWAITING_CONFIRMATION: The match count is ready and confirmation is required.

- DELETING: Confirmed deletion is in progress.

- SUCCEEDED: All matching Entries were deleted.

- PARTIALLY_FAILED: Some matching Entries could not be deleted.

- FAILED: The operation could not be completed.

- UNKNOWN: Current workflow status is unavailable or unrecognized.

While an operation is awaiting confirmation, deletedEntries and percentComplete remain 0.

Idempotent Requests

requestId is a caller-generated idempotency key. It must contain between 1 and 128 letters, numbers, periods, underscores, colons, or hyphens.

Retrying the same input with the same API token and requestId returns the existing operation. It does not create another operation or consume additional rate-limit capacity.

Reusing the same API token and requestId with different deletion input returns IDEMPOTENCY_CONFLICT.

Errors

Request and confirmation errors are returned in the result's error field:

{
  "data": {
    "requestEntryDeletion": {
      "operation": null,
      "error": {
        "code": "RATE_LIMITED",
        "message": "The deletion rate limit has been reached.",
        "retryable": true,
        "retryAfterSeconds": 120,
        "supportReference": null
      }
    }
  }
}

Most request errors return operation: null. If the operation was reserved but its workflow could not be started, requestEntryDeletion can return both a non-null operation and a TEMPORARY_UNAVAILABLE error. Retry that request with the same requestId.

Stable request error codes are:

  • INVALID_INPUT: The input, identifier configuration, or requested operation is invalid.

  • INVALID_STATE: The operation is not awaiting confirmation.

  • INVALID_TEAM: The requested team does not exist.

  • IDEMPOTENCY_CONFLICT: The API token previously used the request ID with different input.

  • RATE_LIMITED: Retry after the returned retryAfterSeconds.

  • TEMPORARY_UNAVAILABLE: A temporary problem prevented the request from being accepted.

Terminal workflow failures appear in operation.error:

  • DELETION_FAILED: The deletion did not complete.

  • DELETION_PARTIALLY_FAILED: Some matching Entries were not deleted.

When an error includes supportReference, provide it to Unwrap Support.

Requests that do not satisfy the API-token authorization requirement return a standard GraphQL authorization error with code UNAUTHORIZED.

Rate Limit

Each API token may create up to 100 deletion operations in a rolling one-hour window.

Idempotent retries that return an existing operation do not count as additional operations.

Disclaimer

Please note that deletions should only be done to remove entries from Unwrap permanently. If you delete large blocks of entries and then require re-ingesting those entries again, this may incur a processing fee as Unwrap incurs costs to re-ingest and re-compute those entries.