Skip to main content

XSIAM Sink Node

The xsiamsink node sends records to a Palo Alto Networks Cortex XSIAM HTTP Collector endpoint. Each record is serialized to JSON and POSTed to the configured endpoint with an API key in the Authorization header.

Key Features​

  • Direct HTTP Collector delivery: posts JSON straight to an XSIAM HTTP Collector endpoint — no forwarder or agent in between
  • API key authentication: the credential's key is sent verbatim as the Authorization header value
  • Per-record error isolation: a failed POST is recorded as an error output for that record while the remaining records in the batch continue
  • Records sent as-is: the record is serialized unchanged, so any XSIAM field shaping is done by upstream nodes

Configuration​

FieldTypeRequiredDefaultDescription
endpointStringYes—XSIAM HTTP Collector URL to POST records to
credentialIdStringYes—ID of an API key credential in jobContext.otherProperties. Its key is sent as the Authorization header
batchSizeIntegerNo100Records buffered per flush cycle. Minimum: 1. See Batching

Authentication​

Store the XSIAM API key as an API key credential:

jobContext:
  otherProperties:
    xsiam-key:
      key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Set credentialId: "xsiam-key" in the sink config. The key's value is placed directly into the Authorization header — include any scheme prefix XSIAM expects in the stored value itself, since the node does not add one.

Each request is sent with Content-Type: application/json.

Batching​

batchSize controls how many records the pipeline buffers before invoking a flush — it does not combine records into one request. Within a flush, each record is serialized and POSTed individually.

So a batchSize of 100 means up to 100 records are handed to the sink at a time, resulting in up to 100 separate HTTP requests. Raising it does not reduce request volume; it only changes how often the flush cycle runs and how many records are exposed to a single failure window.

Failure Handling​

A POST that fails — a network error or a non-success status — is recorded as an error output for that record only. Remaining records in the same flush are still attempted, so one rejected record does not block the others.

Because delivery is per record, a partially failed flush has already delivered some of its records. Retries driven by the error path can therefore duplicate previously delivered records; XSIAM ingestion should be treated as at-least-once.

DAG Example​

jobContext:
  otherProperties:
    xsiam-key:
      key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  metricTags: {}
  dlqConfig:

dag:
  - id: "source"
    commandName: "stdin"
    config:
      encodingType: "JSON_OBJECT_LINE"
    outputs:
      - "sink"

  - id: "sink"
    commandName: "xsiamsink"
    config:
      endpoint: "https://api.xdr.paloaltonetworks.com/public_api/v1/xsiam"
      credentialId: "xsiam-key"
      batchSize: 100