Skip to content
downpipes docs

Send the downpipes audit trail to an endpoint that is not in the list

Every other page in this section names a vendor and pre-selects the wire format and delivery that vendor expects. The Custom endpoint tile is for the destination that is not on the list: you choose the format and the delivery yourself, and the engine pushes the audit trail there on its scheduler tick exactly as it does for a named vendor.

Use it for a SIEM the catalogue does not cover, an in-house collector, a log broker in front of something else, or an HTTPS endpoint you control that simply accepts JSON.

What you choose

Two settings decide the shape of what arrives.

The wire format, one of: raw-json, ndjson, json-array, splunk-hec, datadog, cef, leef or gelf. If your destination has no opinion, ndjson is the easiest to consume, one event per line. If it is a syslog-oriented tool, cef or leef is usually the format it already parses.

The delivery, one of: http (the engine POSTs to your URL), s3 (the engine writes objects into a bucket you own), or syslog-tls (the engine opens a TLS syslog connection).

Nothing else about the push changes. The events, the signing and the retry behaviour are the same ones the named vendor tiles use, which is the point of this tile existing rather than a separate mechanism.

Set it up

  1. Decide the format and delivery your endpoint expects, and have its URL or bucket plus any token ready.
  2. In the console, open Integrations and choose the Custom endpoint tile.
  3. Set the format and delivery, then the destination and its credential. This is owner-only and asks for a fresh step-up sign-in, like every other push change.
  4. Save, then send a test event from the panel and confirm it arrives before relying on it.

Why your custom push may appear under a different tile

This is the part worth reading twice, because it looks like a bug the first time it happens.

The audit push is a single destination for the estate, not one per tile. So the tiles have to agree on which of them owns the live configuration, and they decide by matching the format and delivery. A named vendor’s tile owns the push when the live format and delivery match the pair that vendor pre-selects. The Custom endpoint tile owns it only when no named vendor matches.

The consequence: if you set up a custom push whose format and delivery happen to be the same pair as a catalogue vendor, that vendor’s tile will show your push as live and the Custom endpoint tile will show as available. Choosing splunk-hec over http, for example, is exactly Splunk’s pair, so the Splunk tile takes ownership of the display.

Nothing is misrouted when this happens. Your endpoint is still the destination, the events still go where you pointed them, and the configuration is unchanged. Only the tile the console shows it under differs. If you want the push to appear under Custom endpoint, pick a format and delivery combination that no named vendor uses.

One push at a time

Setting up a push here replaces whatever push was configured before, whichever tile it was configured from. If you need the audit trail in more than one place, send it to a broker or pipeline tool that fans it out, such as Cribl, rather than expecting two pushes.

What you can check afterwards

  • The tile shows live when a push is configured and enabled, and configured when it is set up but switched off.
  • The audit log records the push change itself, with who made it and when, so the configuration is auditable rather than just present.
  • A delivery that fails is visible in the push panel rather than silently dropped, so an endpoint that stops accepting events shows up as a fault instead of as quiet success.
  • A test event is the only thing that proves your endpoint accepts the format you chose. A saved configuration proves the console accepted it, which is a different claim: the format check that matters happens at your end, not ours.

Last updated .