SentinelOne β Alert Ingestion Guide
this guide covers two approaches for ingesting sentinelone alerts into swimlane turbine, normalized to teds format connector β use the sentinelone connector's built in ingestion actions directly in a playbook for full control over your workflow component β use the soc unified alert ingestion sentinelone component for a turnkey pipeline with deduplication, observable enrichment, ti record management, and automated case creation both approaches deliver alerts in swimlane's turbine extendable data schema (teds) format, the same format used across crowdstrike, microsoft graph, and other connectors one downstream playbook handles alerts from any source key capabilities unified alert format β every sentinelone alert is normalized to teds, enabling cross vendor playbooks and dashboards built in enrichment β timeline events, analyst notes, mitigation action results, purple ai investigation verdicts, and raw indicators from the sentinelone data lake incremental polling β only new or updated alerts are fetched on each run, with automatic checkpoint management no duplicates, efficient api usage production ready β handles pagination, scope filtering, error recovery, and high volume environments out of the box using the connector the sentinelone connector includes two purpose built actions for alert ingestion ingest unified alerts and get unified alerts use this approach when you want full control over your playbook logic how it works authenticate β connects to the sentinelone api using the configured asset credentials (api key) query alerts β calls the sentinelone unified alerts graphql api ( /unifiedalerts/graphql ) with scope, time range, and optional filters incremental polling β uses a checkpoint timestamp ( lastupdatedat ) to fetch only new or updated alerts since the last run on the first run, it looks back a configurable number of hours paginate β automatically handles pagination (configurable page size up to 1000, with a max pages safety limit) normalize to teds β each alert is transformed into a teds object containing standardized fields (severity, timestamps, impacted hosts, observables, mitre att\&ck mappings, originating files) enrich β when enrichment is enabled (default), the action automatically fetches and attaches additional context for each alert timeline, history, analyst notes, mitigation actions, purple ai investigations, and raw indicators return β returns the normalized alerts along with a last updated at timestamp for the next polling run the get unified alerts action is a lower level alternative that retrieves raw alert data from the graphql api with granular field level control (50+ skip flags) use this when you need custom processing rather than the built in teds normalization connector setup prerequisites sentinelone api token with access to the target scope (account, site, or group) the sentinelone connector installed from the turbine marketplace your sentinelone account id, site id, or group id steps create an asset β in turbine, create a new sentinelone asset with your api token and management console url create a playbook β create a new playbook with a scheduled trigger (e g , every 5 minutes) add the ingest unified alerts action β add the sentinelone connector's ingest unified alerts action to your playbook configure scope β set the scopetype (account, site, or group) and provide the corresponding scopeids configure first run β set backfillhours (e g , 24 ) or backfilltimestring (e g , "24 hours ago" ) for the initial ingestion window enable incremental polling β store data last updated at from each run and pass it back as lastupdatedat on the next run process alerts β use the teds object output with the "process as teds alert" action to create turbine records automatically authentication api token β sentinelone api token generated from the management console management console url β your sentinelone tenant url using the component the soc unified alert ingestion sentinelone component provides a complete soc ingestion pipeline on top of the connector actions use this approach when you want out of the box alert ingestion with deduplication, observable enrichment, ti record management, and automated case creation what the component adds alert deduplication β checks if an alert has already been ingested by matching alert uid against existing cim records, preventing duplicate cases case creation β creates structured case and incident management (cim) records from teds alerts with all normalized fields observable extraction β parses observables from alert content and file evidence, calculates file hashes, and structures them as teds observables multi provider enrichment β enriches extracted observables using up to five threat intelligence providers virustotal β file hash and url reputation abuseipdb β ip address reputation ipqualityscore β ip and email risk scoring urlhaus β malicious url detection recorded future β threat intelligence context threat intelligence records β creates or updates ti records for each observable new observables trigger enrichment automatically; existing observables get updated last seen timestamps alert correlation β correlates incoming alerts against existing cim records based on shared observables, alert rules, or custom logic knowledge base linking β links relevant knowledge base articles (kbas) to cases based on signal source and alert rules how it works ingest alerts β uses the sentinelone connector's ingest unified alerts action to retrieve new alerts with incremental polling deduplicate β each alert's alert uid is checked against existing cim records duplicates are skipped extract observables β the ioc parser and file extraction components identify observables (domains, ips, file hashes, emails, urls) from alert content and attached files enrich observables β each observable is sent through configured ti enrichment providers results (verdicts, risk scores, context) are appended to the observable create ti records β each enriched observable is saved to a threat intelligence record correlate β the alert is checked for correlation with existing cases based on shared observables and alert rules create case β a cim record is created with the full teds alert, enriched observables, ti tracking ids, kba references, and correlation data component setup prerequisites sentinelone api token with access to the target scope the sentinelone connector installed from the turbine marketplace the soc unified alert ingestion sentinelone component imported from the marketplace a turbine application with case and incident management (cim) and threat intelligence (ti) record types configured (optional) assets for enrichment providers virustotal, abuseipdb, ipqualityscore, urlhaus, recorded future steps create an asset β in turbine, create a new sentinelone asset with your api token and management console url install the component β import the soc unified alert ingestion sentinelone component from the marketplace configure enrichment β set up assets for the ti enrichment providers you want to use the component will use whichever providers have valid assets configured configure the component β set the scope, polling interval, and enrichment preferences within the component configuration schedule the playbook β the component handles checkpointing, deduplication, enrichment, and record creation automatically on each scheduled run recommended configuration scenario pagesize maxpages backfillhours enableenrichment initial deployment 500 100 24 true production polling (every 5 min) 100 10 β true high volume environments 1000 1000 β false testing 100 1 1 true teds output schema both the connector and component produce alerts in this standardized format teds field type description alert uid string unique alert identifier alert title string alert display name alert description string description of what was detected alert severity string critical , high , medium , low alert provider string "sentinelone" alert categories array e g , \["malware"] alert created timestamp string iso 8601 creation time alert start timestamp string when the threat was first observed alert end timestamp string last update time alert ingested timestamp string when the alert was ingested alert impacted hostnames array affected endpoint hostnames alert impacted ip addresses array affected endpoint ips alert impacted usernames array affected user accounts alert originating files array file paths that triggered the alert observables array objects with observable type and observable value (sha256, file names, ips, domains) alert rules array objects with rule name , rule type , rule description signal source string source signal type raw alert object complete original sentinelone alert enrichment data ( alert metadata ) when enrichment is enabled, each alert also includes field type description alert notes array analyst notes (id, text, timestamp) alert timeline array detection and status change events alert history array alert state change history alert mitigation actions array remediation actions taken (quarantine, kill, etc ) ai investigations array purple ai analysis verdict and summary raw indicators array raw indicators from the sentinelone data lake sample output { "teds object" { "alert uid" "019866b7 d9e1 7c8b a7c2 3cd553dd3d24", "alert title" "property spray js detected as malware", "alert description" "windows file events analysis detected suspicious activity", "alert severity" "medium", "alert provider" "sentinelone", "alert categories" \["malware"], "alert created timestamp" "2025 08 01t17 38 58 343z", "alert start timestamp" "2025 08 01t17 38 58 331z", "alert end timestamp" "2025 12 27t09 52 26 907z", "alert impacted hostnames" \["s1demojs"], "alert impacted ip addresses" \["192 168 1 100"], "alert impacted usernames" \["admin"], "alert originating files" \["c \\\users\\\admin\\\downloads\\\property spray js"], "observables" \[ {"observable type" "sha256", "observable value" "7069f825 "}, {"observable type" "file name", "observable value" "property spray js"} ], "alert rules" \[ {"rule name" "agent policy", "rule type" "reputation", "rule description" "windows file events analysis detected "} ], "signal source" "alert" }, "alert metadata" { "alert notes" \[{"text" "investigated and confirmed as false positive"}], "alert timeline" \[{"eventtype" "detection", "eventtext" "alert created"}], "alert mitigation actions" \[{"actiontype" "quarantine", "status" "success"}], "ai investigations" \[{"verdict" "suspicious", "summary" "ai analysis suggests suspicious behavior"}] } } connector reference for the full list of actions, input/output schemas, and authentication setup, see the https //docs swimlane com/connectors/sentinelone