Get event details from cases and detections

This page complements the Events GraphQL API guide. Use it when you start from a case or a detection, and you need the telemetry underneath it.

What this covers¶

This guide follows both chains through to the event fields an integration reads first: summary, eventTime, eventType, and values. It also shows how to add the MITRE ATT&CK techniques for an event.

The Cases, Detections, and Events GraphQL APIs share one endpoint. Each step below is a separate request to that endpoint.

This guide doesn't cover searching for events. The Events GraphQL API retrieves events by ID only. For the current search options, see Search and filter events.

Prerequisites¶

• Create a service principal and get a bearer token. See the Events GraphQL API guide.
• Get a case ID from cases, or a detection ID from detectionSearch.
• Send every request below to the same endpoint, with the same bearer token and X-Tenant-ID header.

Workflow¶

Both chains take three steps:

1. Ask the case or the detection for its event IDs.
2. Pass those IDs to events as resource names.
3. Select the event fields your integration needs.

An event ID is an event resource name. Pass the value to EventsInput.rns unchanged. Don't parse it, and don't construct one yourself.

Start from a case, or from a detection.

Get events from a case¶

Step 1: list the case's evidence¶

caseEvidence returns the evidence attached to one case as IDs. For what the evidence fields mean, see Manage the case lifecycle.

Query

query CaseEvidenceIds($arguments: CaseEvidenceArguments!) {
  caseEvidence(arguments: $arguments) {
    eventsEvidenceCount
    eventsEvidence {
      eventId
      isGenesis
    }
    detectionsEvidenceCount
    detectionsEvidence {
      detectionId
    }
  }
}

{
    "arguments": {
        "id": "<case-id>"
    }
}

Response

{
    "data": {
        "caseEvidence": {
            "eventsEvidenceCount": 2,
            "eventsEvidence": [
                { "eventId": "<event-id-1>", "isGenesis": true },
                { "eventId": "<event-id-2>", "isGenesis": false }
            ],
            "detectionsEvidenceCount": 1,
            "detectionsEvidence": [
                { "detectionId": "<detection-id>" }
            ]
        }
    }
}

Collect the event IDs from eventsEvidence[].eventId. A case also carries detection IDs. Follow the detection chain for each detectionsEvidence[].detectionId.

Step 2: retrieve the events¶

Pass the collected IDs to events in one request.

Query

query CaseEvents($input: EventsInput!) {
  events(input: $input) {
    rn
    eventType
    summary
    eventTime
    ingestTime
    values
  }
}

{
    "input": {
        "rns": ["<event-id-1>", "<event-id-2>"]
    }
}

Response

{
    "data": {
        "events": [
            {
                "rn": "<event-id-1>",
                "eventType": "PROCESS",
                "summary": "\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -enc <encoded-command>",
                "eventTime": "2026-09-04T22:10:44.929917Z",
                "ingestTime": "2026-09-04T22:11:12.164403Z",
                "values": {
                    "commandline": "\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -enc <encoded-command>",
                    "hostname": "<hostname>",
                    "image_path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
                    "sensor_type": "<sensor-type>"
                }
            }
        ]
    }
}

summary is the standardized, human-readable description of the event. eventTime is when the sensor registered the event, and ingestTime is when the platform received it. Compare the two when you investigate a reporting delay.

values holds the normalized telemetry as a JSON object. Its keys depend on eventType, so read eventType first and key your parser off it. The EventType reference lists every type this API returns.

Get events from a detection¶

Step 1: read the detection's event IDs¶

detectionRetrieveById returns detection records for the IDs you pass. Select event_ids to get the events that contributed to each detection.

Query

query DetectionEventIds($in: GetByIDRequestInput) {
  detectionRetrieveById(in: $in) {
    alerts {
      list {
        id
        metadata {
          title
        }
        event_ids {
          id
        }
      }
    }
  }
}

{
    "in": {
        "iDs": ["<detection-id>"]
    }
}

Response

{
    "data": {
        "detectionRetrieveById": {
            "alerts": {
                "list": [
                    {
                        "id": "<detection-id>",
                        "metadata": {
                            "title": "Suspicious PowerShell activity"
                        },
                        "event_ids": [
                            { "id": "<event-id-1>" },
                            { "id": "<event-id-3>" }
                        ]
                    }
                ]
            }
        }
    }
}

Each event_ids entry carries an ID. Collect those IDs for the next request.

Step 2: retrieve the events¶

Use the same events query as step 2 of the case chain, with the detection's event IDs.

{
    "input": {
        "rns": ["<event-id-1>", "<event-id-3>"]
    }
}

Add attack technique details¶

additionalData holds data beyond the normalized values. Select mitreAttackTechniques to get the MITRE ATT&CK techniques for each event. The federated endpoint resolves these fields through the MITRE ATT&CK subgraph.

Query

query EventTechniques($input: EventsInput!) {
  events(input: $input) {
    rn
    eventType
    summary
    additionalData {
      mitreAttackTechniques {
        id
        technique_id
        technique
        tactics
      }
    }
  }
}

Response

{
    "data": {
        "events": [
            {
                "rn": "<event-id-1>",
                "eventType": "PROCESS",
                "summary": "\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -enc <encoded-command>",
                "additionalData": {
                    "mitreAttackTechniques": [
                        {
                            "id": "<technique-record-id>",
                            "technique_id": "T1059.001",
                            "technique": "PowerShell",
                            "tactics": ["Execution"]
                        }
                    ]
                }
            }
        ]
    }
}

For the raw packet behind an event, select additionalData.originalData. For the detections an event contributed to, select additionalData.detections. Both are described in the Events GraphQL API guide.

Error handling¶

Check the HTTP status and the GraphQL response body. A request can return HTTP 200 with an errors array.

The events response can hold fewer entries than the number of IDs you sent. Compare the returned rn values against the IDs in your request, rather than matching entries by position.

For transport failures, such as an expired token or a rate limit, see Errors.

Constraints and considerations¶

• Batch the IDs. EventsInput.rns takes a list, and one request for 20 events costs far less against the rate limits than 20 requests.
• values keys depend on eventType. Don't assume one event type's keys apply to another.
• additionalData loads only when you select it, and that selection can increase retrieval time.
• A case's event evidence and a detection's event_ids are separate sets. Merge them, and remove duplicates, when you want every event behind a case.

Related operations¶

• Events GraphQL API guide
• Cases GraphQL API guide
• Detections GraphQL API guide
• Manage the case lifecycle
• events
• caseEvidence
• detectionRetrieveById