We've reorganized our documentation navigation structure to align directly with your operational workflows. See the release notes and the walkthrough video for more information.

DeleteCollector parity mapping

Supported in:

Google secops SIEM

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

Protocol and mapping overview

Feature	Legacy API (`DeleteCollector`)	Modern Chronicle API (`DeleteCollector`)
HTTP method	`DELETE`	`DELETE`
Permissions	Partner token or legacy API keys	`chronicle.googleapis.com/collectors.delete`

Request payload field-by-field parity

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

Legacy field (`DeleteCollectorRequest`)	Modern field (`DeleteCollectorRequest`)	Field type	Parity and migration notes
`name`	`name` (in HTTP path)	`string`	Google Cloud scoping context: The legacy request used path format `forwarders/<forwarder_id>/collectors/<collector_id>`. The modern API routes this using the standard Google Cloud resource tree structure: `projects/{project}/locations/{location}/instances/{instance}/forwarders/{forwarder_id}/collectors/{collector_id}`.

Response payload field-by-field parity

Both APIs return an empty response message.

Legacy field	Modern field	Field type	Parity and 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 forwarders/<forwarder_id>/collectors/<collector_id> are migrated to standard Google Cloud path parameters projects/{project}/locations/{location}/instances/{instance}/forwarders/{forwarder_id}/collectors/{collector_id}.