Elastic Security + Stream Deck

Set the workflow status of one or more Elastic Security alerts (signals) by ID via POST /api/detection_engine/signals/status. Run Search Alerts first to obtain signal IDs. Example: calling with alertStatus: "closed", signalIds: ["abc123"], reason: "false_positive" returns { updated: 1, version_conflicts: 0 }. View docs

Search Elastic Security detection alerts (signals) via POST /api/detection_engine/signals/search using raw Elasticsearch Query DSL. Use this to find alert IDs before running Update Alert Status, or to investigate alert volume/details for a case. Returns the raw Elasticsearch search response with a hits.hits array; each hit's _id is the signal ID and _source holds the alert's full ECS document. Example: calling with query: {"bool":{"filter":[{"term":{"kibana.alert.workflow_status":"open"}}]}} and size: 5 returns { hits: { total: { value: 12 }, hits: [{ _id: "abc123", _source: { "@timestamp": "...", "kibana.alert.workflow_status": "open", "host.name": "..." } }, ...] } }. Omit query to match all alerts. _source always holds the full ECS document; use fields to additionally get a compact, array-valued view of just the fields you need (under each hit's fields key) without parsing the full document yourself. View docs

Manually run one or more Elastic Security detection rules over a time range via POST /api/detection_engine/rules/_bulk_action (bulk action run). Use this to test a rule immediately instead of waiting for its next scheduled interval, or to backfill detections over a past window. Provide the rule ids to execute. Run Find Detection Rules first to obtain valid ids. Defaults to roughly the last hour if not specified: endDate defaults to one minute ago (a small buffer so clock skew/latency can't push it into the future, which Kibana rejects), and startDate defaults to one hour before that. Note: Kibana rejects manual runs against disabled rules — the rule must have enabled: true (see Create or Update Detection Rule). Example: calling with ids: ["7ac3..."] and no dates returns { attributes: { results: { created: [{ id: "7ac3...", name: "..." }] }, summary: { succeeded: 1, failed: 0 } } }. View docs

List all unique tags currently in use across Elastic Security cases via GET /api/cases/tags, or detection rules via GET /api/detection_engine/tags. Use this before tagging a case or rule so you reuse an existing tag instead of creating a near-duplicate (e.g. incident-response vs. incident_response). Cross-referenced by the tags parameter on Create or Update Case, Create or Update Detection Rule, and Find Cases. Example: calling with objectType: "case" returns ["council-jurassic-eval", "ransomware", "insider-threat"]. View docs and the View docs

Find and list Elastic Security detection rules via GET /api/detection_engine/rules/_find, or fetch a single rule directly via GET /api/detection_engine/rules when id or ruleId is provided. Use this to search/browse rules, or to look up one rule's full definition once you have an ID. Run this first to obtain an id/ruleId before using Create or Update Detection Rule, Run Detection Rule, or Delete Record. Example: calling with filter: 'alert.attributes.enabled: true' returns { total: 3, data: [{ id: "7ac3...", name: "InGen Perimeter Query Rule", type: "query", enabled: true, ... }] }; use fields to shrink each rule down to just the fields you need — rule objects carry many advanced fields (exceptions_list, related_integrations, threat, etc.) that are rarely relevant. View docs

Find and list Elastic Security cases via GET /api/cases/_find, or fetch a single case directly via GET /api/cases/{caseId} when caseId is provided. Use this to search/browse cases, or to look up one case's full details (including its version token) once you have an ID. Run this first to obtain a caseId before using Create or Update Case, Add Case Comment, or Delete Record. Example: calling with search: "perimeter breach" and status: "open" returns { total: 1, cases: [{ id: "a1c1...", title: "Isla Nublar Perimeter Breach", severity: "high", status: "open", ... }] }; use fields to shrink each case down to just the fields you need. View docs

List users who have created or reported Elastic Security cases, via GET /api/cases/reporters, to discover valid profile_uid values for the assignees parameter on Create or Update Case. Kibana has no public endpoint for listing every org user or for listing who is eligible for assignment — this endpoint only covers people who have reported at least one case, which is a subset of valid assignees, not the full set. If the person you need doesn't appear here (e.g. they've never reported a case), ask the user for their profile_uid directly instead of guessing. Example: calling with no parameters returns [{ username: "jsmith", full_name: "Jane Smith", email: "jane@example.com", profile_uid: "u_abc123_cloud" }]; pass that profile_uid as an entry in Create or Update Case's assignees array. View docs

Permanently delete an Elastic Security case or detection rule by ID. Cases are deleted via DELETE /api/cases; detection rules via DELETE /api/detection_engine/rules. Run Find Cases or Find Detection Rules first to obtain a valid ID for the object you want to delete. Example: calling with objectType: "case" and recordId: "a1c1..." returns { success: true, objectType: "case", recordId: "a1c1..." }. This is destructive and cannot be undone. View docs and the View docs