Rapid7 InsightIDR

SIEM Platform

Synopsis

The Rapid7 InsightIDR target forwards events to a Rapid7 InsightIDR log HTTP ingestion endpoint over HTTPS. It handles batching and delivery — the event payload is expected to already be a complete JSON document in InsightIDR's schema when it reaches the target.

Schema

- name: <string>
  description: <string>
  type: rapid7
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    url: <string>
    api_key: <string>
    batch_size: <integer>
    timeout: <integer>
    field_format: <string>
    debug:
      status: <boolean>
      dont_send_logs: <boolean>

Configuration

The following fields are used to define the target:

Field	Required	Default	Description
name	Y		Target name
description	N	-	Optional description
type	Y		Must be rapid7
pipelines	N	-	Optional post-processor pipelines
status	N	true	Enable/disable the target

Connection

Field	Required	Default	Description
url	Y	-	Rapid7 InsightIDR log HTTP ingestion endpoint. The ingestion token is embedded in the URL, e.g. `https://<region>.data.logs.insight.rapid7.com/v1/input/hook/<TOKEN>`
api_key	N	-	Optional value sent as the x-api-key header, for endpoints that require it in addition to the embedded token

Batch Configuration

Field	Required	Default	Description
batch_size	N	1000	Maximum events per POST, serialized as newline-delimited JSON
timeout	N	30	HTTP client timeout, in seconds

Processing

Field	Required	Default	Description
field_format	N	-	Optional target-side normalization format applied before delivery. Typically left empty, since the payload already arrives in InsightIDR's JSON schema from upstream processing. See applicable Normalization section

Scheduling

See Scheduling and Pool Behavior for interval and cron fields shared by all targets.

Debug Options

Field	Required	Default	Description
debug.status	N	false	Enable debug logging
debug.dont_send_logs	N	false	Process logs but don't send to target (testing)

Details

This target is transport-only: it does not render InsightIDR's log schema itself. It expects each event to already be a complete JSON document when it reaches the target, buffers events in memory, and delivers them as one HTTP POST — newline-delimited JSON, one document per line — once batch_size is reached or during finalization.

Endpoint and Authentication

The url is the InsightIDR log HTTP ingestion endpoint; the ingestion token is embedded directly in the URL path. api_key is optional and only needed if the endpoint additionally requires an x-api-key header. Configuration validation rejects a target with no url.

Batching and Retry

Events buffer until batch_size is reached, then POST as a single request. A failed POST does not retry the batch internally: the buffer is cleared unconditionally after Finalize, and delivery failure is surfaced to the sender pool, which handles redelivery through the JetStream layer. Retaining the batch locally in addition to that redelivery would duplicate events at the destination. Error responses include up to the first 1 MB of the response body for troubleshooting.

note

The target does not render InsightIDR's JSON schema — it only batches and delivers the payload it receives. Format the event as InsightIDR-compatible JSON before it reaches this target.

Examples

Basic Configuration

Sending JSON events to a Rapid7 InsightIDR log HTTP endpoint...

targets: - name: rapid7 type: rapid7 properties: url: "https://us.data.logs.insight.rapid7.com/v1/input/hook/TOKEN"

With API Key Header

Adding an x-api-key header for endpoints that require it alongside the embedded token...

targets: - name: rapid7-authenticated type: rapid7 properties: url: "${RAPID7_LOG_ENDPOINT}" api_key: "${RAPID7_API_KEY}"

High-Volume Configuration

Increasing batch size and timeout for high-volume ingestion...

targets: - name: rapid7-high-volume type: rapid7 properties: url: "${RAPID7_LOG_ENDPOINT}" batch_size: 5000 timeout: 45