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).

The two are not independent, and both the console and the engine refuse the pairings that cannot work rather than shipping bytes the receiver will not read. syslog-tls carries cef or leef and nothing else, because an RFC 5424 record’s message is a CEF or a LEEF line. In the other direction, cef and leef require syslog-tls, because no SIEM parses raw CEF or LEEF posted over HTTP. Choosing either half of a refused pair blocks the save, with the reason stated on the form.

The s3 delivery uses the format like every other sink: the object it writes holds the batch in the format you picked, and its key ends with an extension describing how to read those bytes, .json or .ndjson. What s3 cannot carry is cef or leef, refused by the pairing rule above like any other sink that is not syslog-tls.

Nothing else about the push changes. The events 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. This is the one tile that leaves both settings to you, so set Format and Delivery here, then the destination and its credential. This is owner-only and may ask for a fresh step-up sign-in, like every other push change.
4. Choose Configure to save. If a second owner must approve push changes, nothing changes until they do. A new destination is saved with the box ticked, so it starts draining on the next scheduler tick; clear Enabled first if you would rather prove the endpoint before any real event leaves. On the s3 delivery, leave it ticked: that sink’s Enable and Disable button is refused, because the engine’s redacted view carries no access key id, so turning it back on means Replace and re-entering the key.
5. Choose Test send and confirm the event arrives. A test send works whether the destination is enabled or not, and never advances the delivery cursor. On http or syslog-tls, choose Enable afterwards if you cleared it. From console 0.2.7, these buttons stay on this tile for every pair, as the next section explains.

Which tile shows your custom push

The audit push is a single destination for the estate, not one per tile. Each tile tags the push with its own identity when you save it. From console 0.2.7, the Custom endpoint tile tags the push custom-endpoint. The Custom endpoint tile then shows the push as its own for every format and delivery pair, with its Test send, Enable, Disable and Replace. A named vendor tile does not show a push tagged custom-endpoint, even when the pair is the one that vendor uses.

A push that you saved from the Custom endpoint tile before console 0.2.7 has no tag, so the console matches it by its format and delivery pair. When the pair matches no named vendor, the Custom endpoint tile shows the push as its own. When the pair matches a named vendor, that vendor’s tile shows the push, and the Custom endpoint tile reads as not set up. For example, splunk-hec over http is the pair that Splunk and CrowdStrike use, so both of those tiles show it. The default ndjson over http matches several named tiles, such as Sumo Logic.

To move an untagged push to the Custom endpoint tile, choose Set up Custom endpoint on that tile and enter the destination again. Replace from a named tile writes that vendor’s tag, and from then on only that tile shows the push.

Nothing is misrouted either way. Your endpoint is still the destination and the events still go where you pointed them; only the tile the console shows it under can differ.

What you can check afterwards

• The tile that shows the push reads “Active” when the push is enabled, and “Off” 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 25 September 2026.