Tool
CrowdStrike Falcon
Falcon's public API is a genuine OAuth2 REST API with scoped clients, and CrowdStrike publishes a full endpoint reference without making you log in first, which is rarer than it should be. Two things shape every integration you will build against it. First, the Event Streams API is a persistent connection, not a poll: you hold it open, you track an offset per feed, and you reconnect from that offset. Second, that connection is keyed on an appId that must be unique per Falcon instance, and a second connection using the same appId is refused rather than queued. Almost every "the SIEM stopped getting Falcon data" story ends at one of those two facts.
What the API exposes
- An OAuth2 client credentials model. You create an API client in the Falcon UI under Support, API Clients and Keys, tick the scopes it needs, and are shown the secret exactly once.
- Event Streams, listed at GET /sensors/entities/datafeed/v2 with the Event streams READ scope. It returns the list of data feed URLs your client should connect to, in json or flatjson format.
- A session refresh action at POST /sensors/entities/datafeed-actions/v1/{partition} with action_name=refresh_active_stream_session, so a long-lived consumer can keep its stream alive.
- Per-event offset values inside each feed, which are the reconnection marker after a dropped connection.
- Host actions at POST /devices/entities/devices-actions/v2 with the Hosts WRITE scope, covering contain, lift_containment, hide_host, unhide_host, suppress_detections and unsuppress_detections. Network containment really is an API call, not just a console button.
- Host search and detail endpoints, device login history, network address history and Falcon Grouping Tag updates.
- Separate regional API gateways, currently api.crowdstrike.com, api.us-2.crowdstrike.com, api.laggar.gcw.crowdstrike.com for US GovCloud, and api.eu-1.crowdstrike.com.
- A first-party technical add-on for Splunk that CrowdStrike itself writes, ships on Splunkbase and supports.
What it cannot do
- Share an appId. If a client connects to Event Streams with an appId that another connection already holds, the new connection is refused. Two collectors, or a collector you forgot you left running in a lab, and one of them silently gets nothing.
- Redirect you to the right cloud. A credential is bound to one regional gateway and CrowdStrike's Splunk add-on documentation states plainly that it does not support redirection. Point it at the wrong base URL and you get an auth failure, not a helpful hop.
- Give you a single feed. A busy instance is split across several data feed URLs, each with its own offset, and a consumer that connects to only the first one quietly collects a fraction of the data.
Capabilities
Connects to
Evidence
- CrowdStrike API reference, Event Streams collection
Source of both Event Streams endpoints, their scopes, the appId and format parameters, and the 32 character alphanumeric limit on appId.
VENDOR DOC · Checked
- CrowdStrike API reference, Hosts collection
Source of the device actions endpoint, its Hosts WRITE scope and the full list of allowed action_name values including contain and lift_containment.
VENDOR DOC · Checked
- CrowdStrike Falcon Event Streams Add-on Installation and Configuration Guide, v3.5+
CrowdStrike's own PDF. Source of the API scope setup, the four regional base URLs, the "does not support redirection" statement, multiple data feed URLs with per-feed offsets, and the appId collision behavior.
VENDOR DOC · Checked