> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Stream audit logs to your SIEM

> Send your Devotel Orbit audit trail continuously to Splunk (HTTP Event Collector), Datadog Logs, Amazon S3, or an HTTPS log drain with native vendor-formatted connectors

# Stream audit logs to your SIEM

This page covers **SIEM sinks** — configured connectors that stream your
workspace's audit trail to the observability platform your security team
already runs: Splunk (HTTP Event Collector), Datadog Logs, a tenant-owned
Amazon S3 bucket, or a generic HTTPS log drain.

If your SOC policy says every audit event must land in your own SIEM, this is
the control to configure before your first compliance review.

<Warning>
  This page describes Devotel Orbit's platform controls. It is **not legal
  advice.** Your audit and retention obligations depend on your industry,
  your regulators, and your contracts. Confirm the specifics with qualified
  counsel.
</Warning>

***

## Why a SIEM sink and not just the webhook

Orbit already publishes every audit event as an HMAC-signed
`audit.log.created` webhook (see [Audit log](/guides/audit-log)). That gives
you a push channel — but the payload is Orbit's generic JSON envelope. If you
point it at Splunk HTTP Event Collector or the Datadog Logs intake, your team
must stand up its own receiver, reshape the payload into each vendor's native
ingest contract, and POST it on.

SIEM sinks close that gap. You register the delivery target once per sink
type, and Orbit delivers each audit event in the vendor's native format
directly to:

| Sink type     | What it is                                                                                                           | Endpoint shape                                             |
| ------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| `splunk_hec`  | Splunk HTTP Event Collector — events land in your Splunk index over HEC                                              | `https://splunk.example.com:8088/services/collector/event` |
| `datadog`     | Datadog Logs intake API — events land in your Datadog logs pipeline                                                  | `https://http-intake.logs.datadoghq.com/api/v2/logs`       |
| `s3`          | Log-object push into a tenant-owned S3 bucket, for your own ingestion (Security Lake, a Lambda forwarder, Athena)    | `s3://your-bucket/prefix/`                                 |
| `https_drain` | Any HTTPS receiver that accepts a JSON POST per audit event — your own ingestion endpoint or a third-party forwarder | `https://logs.example.com/ingest/orbit-audit`              |

Each sink can carry an optional **event-category filter** (the same
mini-language as the `audit.log.created` webhook stream — e.g. `security` or
`authentication,deletion`; omit it to stream every category), so a Splunk
sink can receive only security-relevant events while a parallel S3 sink keeps
the full trail.

<Note>
  SIEM sinks stream your workspace's audit trail to a destination you own.
  They perform no outbound messaging and change nothing about how audit
  records are created.
</Note>

***

## Endpoints

All routes live under `/api/v1/compliance`. Reads require any authenticated
API key; **writes require an owner or admin key** — audit egress to a
third-party system is a security control.

| Method   | Path                         | Purpose                                                                                             |
| -------- | ---------------------------- | --------------------------------------------------------------------------------------------------- |
| `GET`    | `/siem-sinks`                | List configured sinks, the supported-type catalog, and the resolved posture. Always 200; read-only. |
| `PUT`    | `/siem-sinks/:type`          | Register or update the sink for one type (endpoint, credential reference, category filter, label).  |
| `POST`   | `/siem-sinks/:type/activate` | Mark a `pending` or `paused` sink `active`.                                                         |
| `POST`   | `/siem-sinks/:type/pause`    | Halt delivery on an `active` sink without losing its config.                                        |
| `DELETE` | `/siem-sinks/:type`          | Remove the sink. Delivery stops immediately.                                                        |

Every mutating call is itself recorded in your audit log.

The `GET` response has three parts:

* **`sinks`** — one entry per configured type with its endpoint, category
  filter, label, lifecycle state, and timestamps (created, updated, activated,
  paused, last successful delivery).
* **`types`** — the supported-type catalog: label, description, an endpoint
  example, the endpoint format hint, whether the type requires a credential
  reference, and the vendor's documentation URL.
* **`posture`** — the resolved posture: `configured_count`, `active_count`,
  `active_types`, and `streaming` (`true` when at least one sink is actively
  delivering). The dashboard reads this to show whether your audit trail is
  flowing to your SIEM.

***

## Lifecycle: pending → active → paused

A sink is a connector with an explicit state, not a checkbox:

| State     | Meaning                                                                                  |
| --------- | ---------------------------------------------------------------------------------------- |
| `pending` | Configured but not delivering. A new sink — or one whose endpoint changed — starts here. |
| `active`  | Delivering. Only active sinks receive the audit stream.                                  |
| `paused`  | Config retained, delivery halted. Resume with `activate`.                                |

Two transitions are deliberately strict:

**A changed endpoint must be re-activated.** Updating an existing sink with a
new endpoint resets it to `pending`, so you cannot silently redirect a live
audit feed to a new destination without confirming the target. Updates that
keep the same endpoint (changing the filter or label) preserve the current
state.

**Activation is gated on readiness.** `POST .../activate` checks that the
endpoint is well-formed for the sink type and — for types that authenticate
(`splunk_hec`, `datadog`, `s3`) — that a credential reference is recorded. A
hard config failure is rejected with `409 SIEM_SINK_NOT_READY`, so a sink
that cannot deliver is never brought live. Other activation conflicts:
`404 SIEM_SINK_NOT_FOUND` when no sink of that type exists, `409
SIEM_SINK_ALREADY_ACTIVE` when it is already delivering. Pause similarly
rejects a non-active sink with `409 SIEM_SINK_NOT_ACTIVE`.

***

## Credentials are never echoed

A sink stores a **credential reference** — a secret-manager alias such as
`siem/splunk/acme-hec-token` — never the credential material itself. To keep
even that alias from leaking to a lower-privileged viewer, no read response
ever returns it: `GET /siem-sinks` reports only `has_credential: true | false`
per sink. Provision the actual token or role in your secret manager and
record its alias on the sink.

***

## Examples

Replace `dv_live_sk_...` with an owner or admin API key for the write calls.

### Read the current configuration and posture

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/compliance/siem-sinks \
  -H "X-API-Key: dv_live_sk_..."
```

### Splunk (HTTP Event Collector)

```bash theme={null}
curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/splunk_hec \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "https://splunk.example.com:8088/services/collector/event",
    "credential_ref": "siem/splunk/acme-hec-token",
    "category_filter": "security",
    "label": "Splunk prod — security events"
  }'

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/splunk_hec/activate \
  -H "X-API-Key: dv_live_sk_..."
```

The endpoint must be a well-formed HTTPS URL; a malformed one is rejected
with `409 SIEM_SINK_INVALID_ENDPOINT`.

### Datadog Logs

```bash theme={null}
curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/datadog \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "https://http-intake.logs.datadoghq.com/api/v2/logs",
    "credential_ref": "siem/datadog/acme-api-key"
  }'

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/datadog/activate \
  -H "X-API-Key: dv_live_sk_..."
```

### Amazon S3

The only sink type whose endpoint is an S3 URI rather than an HTTPS URL:

```bash theme={null}
curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/s3 \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "s3://acme-audit-logs/orbit/",
    "credential_ref": "siem/s3/acme-audit-logs-role",
    "category_filter": "authentication,deletion"
  }'

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/s3/activate \
  -H "X-API-Key: dv_live_sk_..."
```

### HTTPS log drain

A generic drain has no credential requirement — record a reference if your
receiver authenticates, omit it otherwise:

```bash theme={null}
curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/https_drain \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "https://logs.example.com/ingest/orbit-audit"
  }'

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/https_drain/activate \
  -H "X-API-Key: dv_live_sk_..."
```

### Pause or remove a sink

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/s3/pause \
  -H "X-API-Key: dv_live_sk_..."

curl -X DELETE https://api.orbit.devotel.io/api/v1/compliance/siem-sinks/s3 \
  -H "X-API-Key: dv_live_sk_..."
```

***

## Tenant-owned posture

SIEM sinks are a **tenant-owned control**. Orbit delivers your audit events
to the destination you configure, in the vendor format for the sink type —
the destination itself (the Splunk index, the Datadog organization, the S3
bucket and its retention policy, the drain receiver) is yours to provision,
secure, and monitor. Orbit does not retain a copy of the stream beyond its
own audit ledger, and it does not validate your SIEM-side obligations.

Verify the posture from your side: after activation, confirm events are
arriving at the destination, and watch `last_delivery_at` (reported per sink
in `GET /siem-sinks`) as your liveness signal. Pauses and deletions take
effect immediately.

## Related

* [Audit log](/guides/audit-log) — query the ledger and subscribe to the
  generic `audit.log.created` webhook.
* [Immutable archival export](/compliance/archival-export) — tamper-evident
  WORM copies of messages and recordings (batch export, not a live stream).
* [Compliance posture overview](/compliance/posture-overview) — how Orbit
  reports your workspace's controls.