Different GraphQL endpoints for UI and API - different schemas - API cannot query field view on type TimelineAlertEvent

[hkelley]

While developing a GraphQL query in the UI editor,

https://falcon.crowdstrike.com/id-protection/ui-api/data-model-service/graphql

I discovered that the UI editor has some slight differences in schema vs the API endpoint used by PSFalcon

https://api.crowdstrike.com/identity-protection/combined/graphql/v1

Is this a bug?

To repro:

Issue this query in the UI editor

query ($entityIds: [UUID!], $createdBefore: DateTimeInput!, $alertIds: [UUID!], $alertLimit: Int!) {
  incidents(
                  first:1
                , types: [POTENTIAL_RISKY_ACTIVITY]
                , entityQuery: {entityIds: $entityIds}
                , createdBefore: $createdBefore
                , sortKey: START_TIME
                , sortOrder: DESCENDING) {
    nodes {
      incidentId
      type
      severity
      startTime
      endTime
      timeline(includeContextualEvents: true, excludedTypes: [NEW_INCIDENT], alertQuery: {alertIds:$alertIds} , first: $alertLimit) {
        nodes {
          timestamp
          startTime
          endTime
          eventType
          eventId
          eventSeverity
          ... on TimelineAlertEvent {
            alertType
            alertId
            patternId
            view
          }  
        }
      }
    }
  }
}

Set variables to match the entities from one of these alert types: [DailyVolumeAnomalyAlert, DailyTargetVolumeAnomalyAlert]}

{
  "createdBefore": "time of alert",
  "entityIds": [
    "user's object GUID"
  ],
  "alertIds": ["3c5609e0-48d9-467d-8496-8cddc414df7a"],
  "alertLimit": 10
}

Expected behavior

I would have expected identical query results, but the API endpoint returns an HTTP 400 with:

"message": ": Cannot query field \"view\" on type \"TimelineAlertEvent\"."

Additional context

Powershell script to demonstrate the issue in context:

#region Query stuff

$fql = "product:'idp'+name:['ExcessiveDailyUsage','ExcessiveTargetDailyUsage']"

$graphql = @"
query (`$entityIds: [UUID!], `$createdBefore: DateTimeInput!, `$alertIds: [UUID!], `$alertLimit: Int!) {
  incidents(
        first:1
      , types: [POTENTIAL_RISKY_ACTIVITY]
      , entityQuery: {entityIds: `$entityIds}
      , createdBefore: `$createdBefore
      , sortKey: START_TIME
      , sortOrder: DESCENDING) {
    nodes {
      incidentId
      type
      severity
      startTime
      endTime
      timeline(includeContextualEvents: true, excludedTypes: [NEW_INCIDENT], alertQuery: {alertIds:`$alertIds} , first: `$alertLimit) {
        nodes {
          timestamp
          startTime
          endTime
          eventType
          eventId
          eventSeverity
          ... on TimelineAlertEvent {
            alertType
            alertId
            patternId
            view
          }  
        }
      }
    }
  }
}
"@
#endRegion

foreach($alert in Get-FalconAlert -Filter $fql -Limit 1 -Detailed) {

  $alertId = ($alert.id -split ':')[2]
  $entityUuid = $alert.source_account_object_guid
  
  $variables =  @{
    createdBefore = $alert.created_timestamp
    entityIds= ($entityUuid)
    alertIds = ($alertId)
    alertLimit = 10
  } 

Write-Verbose $graphql

  try{
    if($ret = Invoke-FalconIdentityGraph -String $graphql -Variable $variables -ErrorAction Stop) {
      # Match using the alert ID from the detection
      if($identityAlert = $ret.incidents.nodes.alertEvents | ?{$_.alertId -eq $alertId}) {
        $sources = $identityAlert.relatedEvents.nodes.endpointEntity.primaryDisplayName | select-object -unique | sort-object
        $targets = $identityAlert.relatedEvents.nodes.targetEntity.primaryDisplayName | select-object -unique | sort-object
  
        $alert | add-member -notepropertyname "idp_incident" -notepropertyvalue $ret.incidents.nodes.incidentId
        $alert | add-member -notepropertyname "idp_sources" -notepropertyvalue $sources
        $alert | add-member -notepropertyname "idp_source_count" -notepropertyvalue $sources.Count
        $alert | add-member -notepropertyname "idp_targets" -notepropertyvalue $targets
        $alert | add-member -notepropertyname "idp_target_count" -notepropertyvalue $targets.Count  
      }  
    } else {
      Write-Warning "no incidents found"
    }
  } catch {
    throw $_.Exception
  } finally {
    $alert | select-object severity_name,name,description,product,scenario,type,user*,created*,*link*,idp* 
  }
}

[bk-cs]

The UI often uses different APIs than what are published and made available for API clients to use. PSFalcon doesn't have any control over the schema being used in the API endpoint itself. Unless PSFalcon is manipulating the query that gets sent (check with verbose output enabled), you'd have to refer this to CrowdStrike support.

[hkelley]

Agreed - PSFalcon isn't the culprit here. I initially discovered the problem in n8n and toggled over to PSFalcon to validate (and so that Support wouldn't get "distracted" by the other vendor/product name). I already have a case open - will pursue that angle, asking why this one field wouldn't be API-accessible.