DeleteDataTap parity mapping

Supported in:

This guide details the request and response mapping specifications and property parity analysis for migrating from the legacy Backstory Data Tap API (DeleteDataTap) to the modern Chronicle API (DeleteDataTap).

Protocol and mapping overview

Feature Legacy API (DeleteDataTap) Modern Chronicle API (DeleteDataTap)
HTTP Method DELETE DELETE
Permissions Partner token or legacy API keys chronicle.googleapis.com/dataTaps.delete

Request payload field-by-field parity

The modern Chronicle API DeleteDataTapRequest targets resources using Google Cloud resource name paths.

Legacy Field (DeleteDataTapRequest) Modern Field (DeleteDataTapRequest) Field type Parity & Migration Notes
name name (in HTTP path) string Google Cloud Scoping Context: The legacy request used path format dataTaps/<tap_id>. The modern API routes this using the standard Google Cloud resource tree structure: projects/{project}/locations/{region}/instances/{instance}/dataTaps/{id}.

Response payload field-by-field parity

Both APIs return an empty response message.

Legacy Field Modern Field Field type Parity & Migration Notes
google.protobuf.Empty google.protobuf.Empty Empty Parity Mapped: Successful requests return HTTP 200 OK (mapping to an empty response object {}).

Key differences

  • Google Cloud Project Scoping Integration:
    • Scoped natively under parent project instance folder bindings.
  • Resource Path Renaming:
    • Legacy path formats dataTaps/<id> are migrated to standard Google Cloud path parameters projects/*/locations/*/instances/*/dataTaps/<id>.