Tool
Splunk Enterprise and Splunk Cloud Platform
Splunk is almost always the receiving end of a security integration rather than the initiating one. Getting data in is a solved problem: the HTTP Event Collector takes JSON over HTTPS with a token in a header, and most vendors ship a Splunk add-on that does the polling or streaming for you. Getting Splunk to do something to another system is where the work is. The built-in webhook alert action posts an unauthenticated JSON body and nothing more, so any outbound integration against a real API means an add-on from Splunkbase or an alert action you write yourself. The other thing worth knowing before you plan: Splunk Cloud Platform is a materially smaller product than Splunk Enterprise at the ingest edge, and several of the caveats below apply only there.
What the API exposes
- The HTTP Event Collector accepts events over HTTPS at services/collector, services/collector/event and services/collector/raw.
- HEC authenticates per token with the header "Authorization: Splunk <token>", which the documentation notes is case-sensitive. No account credentials go anywhere near the sender.
- HEC tokens are created and read through the management REST API under data/inputs/http, so token provisioning can itself be automated.
- Indexer acknowledgment is available at services/collector/ack against a channel identifier, letting a sender confirm an event actually reached an index rather than just a socket.
- A collector health endpoint at services/collector/health.
- A built-in webhook alert action that POSTs a JSON body to a URL when a saved search fires.
- Modular input add-ons, which run a vendor's Python collector on a heavy forwarder, an Input Data Manager or Splunk Cloud. This is how nearly every SaaS security product gets its data in.
- Custom alert actions, a documented extension point that app developers use to build configurable outbound actions.
What it cannot do
- On Splunk Cloud Platform, indexer acknowledgment is only available for AWS Kinesis Firehose. Every other HEC sender there gets no confirmation that its event was indexed.
- On Splunk Cloud Platform you cannot change HEC global settings at all. You can only change tokens you created yourself.
- HEC will not create an index. The index you name in a token has to exist already.
- On Splunk Cloud Platform you cannot forward data HEC receives on to another set of indexers, because forwarding output groups are not supported there.
- The built-in webhook alert action is documented as a URL plus a fixed JSON body. There is no documented field for a custom header, a bearer token or basic auth, so on its own it cannot authenticate to a REST API that requires one.
- The webhook payload carries only the first result row of the triggering search, alongside the search ID, results link, owner and app. If your alert returns forty rows, thirty-nine of them are not in the callback.
- From Splunk Enterprise 9.0 and Splunk Cloud Platform 8.2203, a webhook URL has to be on the webhook allow list before a triggered alert will call it. New destinations fail silently until an admin adds them.
Capabilities
Connects to
Evidence
- Set up and use HTTP Event Collector in Splunk Web
Source of the token model, and of every Splunk Cloud Platform caveat above, including the line that indexer acknowledgment there is only available for AWS Kinesis Firehose.
VENDOR DOC · Checked
- Splunk REST API reference, input endpoint descriptions
Exact collector paths, the "Authorization: Splunk <token>" header format and its case sensitivity, and the ack endpoint with its channel parameter.
VENDOR DOC · Checked
- Use a webhook alert action
Documents the whole payload, which is a first result row plus search metadata, and the allow list requirement. Documents no authentication field of any kind.
VENDOR DOC · Checked
- Using custom alert actions
Confirms custom alert actions are an app developer extension point, not something an admin configures from the alert screen.
VENDOR DOC · Checked