ListDataTaps 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 (ListDataTaps) to the modern Chronicle API (ListDataTaps).

Protocol and mapping overview

Feature Legacy API (ListDataTaps) Modern Chronicle API (ListDataTaps)
HTTP Method GET GET
Permissions Partner token or legacy API keys chronicle.googleapis.com/dataTaps.list

Request payload field-by-field parity

The modern Chronicle API ListDataTapsRequest requires scoping under a parent Google Cloud instance path.

Legacy Field (ListDataTapsRequest) Modern Field (ListDataTapsRequest) Field type Parity & Migration Notes
parent (in HTTP path) string Google Cloud Scoping Context: Scopes the list target under parent projects using the standard resource name path in the URL. Pattern: projects/{project}/locations/{location}/instances/{instance_uuid}.
page_size page_size int32 Parity Mapped: Pagination page size limits. Rename to pageSize in JSON payloads.
page_token page_token string Parity Mapped: Paging resumption token. Rename to pageToken in JSON payloads.

Response payload field-by-field parity

Both APIs return pagination results with matching nested models.

Legacy Field (ListDataTapsResponse message) Modern Field (ListDataTapsResponse message) Field type Parity & Migration Notes
data_taps data_taps repeated DataTap Parity Mapped: Array list of data taps (with nested field translations evaluated under CreateDataTap or GetDataTap). Rename to dataTaps in JSON.
next_page_token next_page_token string Parity Mapped: Next page resumption token. Rename to nextPageToken in JSON.

Key differences

  • Google Cloud Project Scoping Integration:
    • Scoped natively under parent project instance folder bindings.
  • Explicit Paging Token Behavior:
    • The modern Chronicle API follows standard Google Cloud paging checkpoint logic.