Skip to content

Push Capsule detections, findings, and policy violations into a Databahn pipeline through an HTTP source, so Databahn can normalize them and route them to whichever SIEM or data lake your SOC runs.

Overview

Capsule sends each event to your Databahn HTTP source as it is produced, authenticated with the source's bearer token. Databahn then applies your pipeline's parsing, enrichment, and routing like any other source.

Event typeWhat gets exported
DetectionsReal-time detections raised on agent activity, with full event context
FindingsPosture and configuration findings across your AI inventory
Policy violationsGuardrail and policy breaches, with the full evidence the decision was made on
Capsule event (detection / finding / policy violation)
  → POST to your Databahn HTTP source, as a JSON array, with a bearer token
  → one Databahn record per array element
  → your pipeline parses, enriches, and routes it
  → your SIEM or data lake

This is separate from Settings → Notifications. Notifications push individual alerts to a channel; the SIEM integration streams the full, verbose event record for ingestion and long-term correlation.

Prerequisites

  • A Capsule account with admin access, and the SIEM tab visible under Settings
  • A Databahn account with permission to add a source to a pipeline
  • An HTTP source reachable from the internet over https. If the source runs on a Smart Edge collector inside your network, expose it through a load balancer or gateway with a certificate from a public CA: Capsule verifies the certificate and does not accept self-signed ones.

Step 1: Prepare Databahn

  1. In Databahn, add a new HTTP source to the pipeline that should receive Capsule's events.
  2. Set its authentication to a bearer token and generate the token.
  3. Copy the source's URL and token.

Each request from Capsule is a top-level JSON array whose elements are individual events. Configure the source so that each array element becomes its own record.

The token grants write access to your pipeline. Anyone holding it, together with the URL, can send records into Databahn. Treat it like a password.

Step 2: Create the SIEM integration in Capsule

  1. In Capsule, go to Settings → SIEM and click Add integration.
  2. Set Destination to Databahn.
  3. Enable the event types you want: Detections, Findings, Policy violations.
  4. Choose an Event detail level:
    • Full sends the whole envelope, matching the S3, Splunk, OpenTelemetry, and Rapid7 exports.
    • Compact omits activity message bodies. Use it to cut ingested volume, or where the transcript is not what you search on.
  5. Paste the Source URL from Step 1, exactly as Databahn shows it. Capsule only accepts an https URL and posts to it as given, without adding a path.
  6. Paste the Token. It is stored as a secret and never shown again.
  7. Click Save, then enable the integration. A new integration starts disabled and exports nothing until you turn it on.

When you edit the integration later, leave Token empty to keep the saved one. To rotate it, generate a new token on the HTTP source, paste it into the integration, and save.

Step 3: Verify

Use the row menu's Send test event. Capsule posts a single connection-test event to the source and reports whether Databahn accepted it, with Databahn's error if it did not. The event is a detection.created whose event.detection.detectionType is CAPSULE_CONNECTION_TEST, so it is easy to filter out in your pipeline or downstream.

The Delivery column on the SIEM list shows the outcome of the most recent attempt, and the details drawer shows the last error in full.

Event envelope

Each event carries the same envelope, with the record under event:

{ "schemaVersion": 2, "eventType": "policy_violation.created", "tenantId": "...", "exportedAt": "...", "event": { ... } }

eventType is one of detection.created, finding.created, policy_violation.created. This is the same envelope the other SIEM destinations send, so a tenant exporting to more than one sees identical content. exportedAt is when Capsule sent the event, and the record's createdAt (event.detection.createdAt, event.finding.createdAt, or event.issue.createdAt) is when it was raised. Use createdAt as the event time in your pipeline.

Every event carries its anchor resource in full - id, name, type, external id, parent, and the environment and connector it was discovered through - so events correlate against the rest of your inventory without a lookup.

  • policy_violation.created is self-contained: the violation under event.issue, the policy that raised it under event.policy including its conditions, and the complete finding, detection and activity records the decision was made on.
  • detection.created carries the detection, its evidence, and the session activities it was raised on.
  • finding.created carries the finding, its evidence, and its remediation steps.

Triage state is exported on all three. Secrets Capsule identified in evidence are masked to a short prefix before export, in evidence text and activity message bodies alike.

Policy violations carry Capsule's severity at event.issue.severity, in lower case: low, medium, high, or critical. Capsule does not rank detections or findings, so those events have no severity field.

One violation, one event. A violation is exported once, when it is first raised. If it is later resolved and the same condition re-triggers, Capsule reuses the existing violation and does not emit a second policy_violation.created.

Delivery behaviour

  • Latency - events are sent as they are produced, inline with the detection, finding, or violation being created.
  • Format - each request is a JSON array of events with Content-Type: application/json and Authorization: Bearer <token>, uncompressed, kept under 5 MB.
  • Retries - Capsule retries 429, 5xx, timeouts, and network errors up to twice within 20 seconds, honouring Retry-After. Every other failure is a configuration error and is reported instead.
  • Timeouts - each request has 10 seconds to complete.
  • Redirects - never followed, so events and the token only ever go to the host you configured.
  • Visibility - the outcome of the most recent attempt is shown per integration in Settings → SIEM, with the full error in the details drawer. The token is masked in error text.
  • Backfill - export begins when the integration is enabled. Events raised before that are not sent.

Troubleshooting

The Databahn source URL redirected (HTTP 3xx)

The saved URL is not the one the source listens on, for example it points at a gateway that forwards to it. Copy the URL from the source again and paste it exactly.

Databahn rejected the token (HTTP 401 or 403)

Databahn did not accept the token. Generate a new token on the HTTP source, paste it into the integration, and save.

Databahn has no HTTP source at this URL (HTTP 404)

The source was deleted, or the URL is wrong. Check the source URL saved on the integration against the one Databahn shows.

Databahn rejected the request as too large (HTTP 413)

Switch Event detail to Compact to shrink the events.

This Databahn integration has no token stored

The integration has no saved token. Edit it, paste the token from the HTTP source, and save.

Nothing arrives at all

  • Confirm the integration is enabled and at least one event type is turned on.
  • Use Send test event - it reports the exact error from Databahn.
  • Confirm the source is reachable from the internet over https, with a certificate from a public CA.
  • Events raised before the integration was enabled are not sent. Wait for a new detection, finding, or violation, or send a test event.

Support

For help with this integration, contact support@capsule.security.