Skip to content
downpipes docs

Forward the downpipes audit trail to Panther

Panther receives the downpipes audit trail through an HTTP log source. The engine dials out to the source’s HTTPS URL on the scheduler tick and posts the audit events as a JSON array.

Panther needs one thing first: a schema (a log type) for the events. Until you infer or define one, Panther ingests the raw JSON but does not normalise it into typed fields. This is the difference from Splunk and Datadog, which parse a first-time feed with no schema step.

Because the engine makes the outbound call, a Cloudflare Access perimeter on your console hostname never blocks this: there is no inbound request for Access to turn away.

What you need

  • A Panther role that can add an HTTP log source and define or infer a schema.
  • The HTTP source URL and its auth token, and owner access to the downpipes console.

Set it up

  1. In Panther, create an HTTP log source (under Configure, Log Sources, then the HTTP source type). Choose the auth method Panther offers (for example a Bearer token or a shared-secret header), and note the URL and token.
  2. In the downpipes console, open Integrations and choose this vendor’s tile. Its push panel fixes Delivery to HTTP endpoint and Format to JSON array, with no picker to set either. Setting up the push is owner-only and asks for a fresh step-up sign-in. Paste the Panther source URL into Endpoint URL.
  3. If you would rather build a HEC-shaped Panther source instead, skip this vendor’s tile and use Custom endpoint to pick Splunk HEC yourself, pointed at that source.
  4. Set Auth header name to match the method you chose in Panther. For a Bearer token, leave it as Authorization and paste Bearer <token> as the Auth secret.
  5. In Panther, infer a schema from the sample data or define one by hand, so the audit fields become typed columns.
  6. Leave Enabled ticked to start draining on the first scheduler tick after you save, or clear it to test before any real event leaves. Choose Configure to save.
  7. Choose Test send and confirm Panther accepts it. A test send works whether the destination is enabled or not, and never advances the delivery cursor. If you cleared Enabled, choose Enable now.

What lands in Panther

Each batch arrives as a JSON array of raw audit events:

[{"seq":4097,"ts":"2026-06-19T02:14:08.221Z","actorEmail":"ops@acme.example","action":"restore-approve","outcome":"success","...":"..."}]

Panther applies the schema you defined, so action, outcome, actorEmail, seq and the rest become queryable columns. The ts field is the event time.

Good to know

  • Define the schema before you rely on searches. Panther normalises the audit events only once the log source has an inferred or hand-written schema; until then the JSON is stored but not typed.
  • Panther caps a POST at 1 MB, and delivery is at-least-once. The engine drains up to 500 small events per tick, under the cap, and a larger backlog drains over successive ticks; dedup on the stable seq or hash. The feed carries operator identity (member emails, source IPs, roles and approver emails); no backup data and no secret values. For the shared push mechanics and the pull alternative, see forwarding the audit log to your SIEM.

Last updated .