Skip to main content

Overview

The SentinelOne destination forwards Ocean events to your Singularity Data Lake (SDL / AI-SIEM) using its Scalyr-derived addEvents HTTP ingest API. Events arrive as structured records (one record per Ocean event) with flat attributes, ready to power AI-SIEM dashboards, correlation rules, and PowerQuery investigations. For an introduction to event types, payloads, and delivery semantics, see the SIEM Forwarding Overview.

Prerequisites

Before configuring the destination in Ocean, gather two values from your SentinelOne SDL tenant:
  • The Ingest URL — your region’s addEvents endpoint, of the form https://xdr.<region>.sentinelone.net/api/addEvents (the exact host depends on your SDL deployment region).
  • A Write API Key — a token authorized to write events into SDL. Treat this as a secret. Ocean places this value in the request body’s token field on every POST.
You also need a SentinelOne account with permission to create and view write API keys for your Singularity Data Lake.
Ocean delivers over HTTPS only. The Ingest URL must start with https:// and must end in /api/addEvents.

Get the ingest URL and write API key

  1. In the SentinelOne console, open Singularity Data Lake (sometimes labeled AI-SIEM or XDR).
  2. Navigate to Settings → API Keys (the exact menu name varies by SDL release — look for the screen that lists log-ingest tokens).
  3. Note your region in SDL. SentinelOne’s documented ingest hosts are:
    RegionIngest host
    USxdr.us1.sentinelone.net
    CAxdr.ca1.sentinelone.net
    EMEAxdr.eu1.sentinelone.net
    APxdr.ap1.sentinelone.net
    APSxdr.aps1.sentinelone.net
    AUxdr.apse2.sentinelone.net
    The full Ingest URL Ocean needs is https://<region-host>/api/addEvents.
  4. Create (or copy an existing) Write API Key scoped for event ingestion. Store it securely — Ocean stores it encrypted and never displays it again.
You can validate the URL + key combo from your machine before configuring Ocean:
curl -i -X POST \
  -H "Content-Type: application/json" \
  "https://xdr.<region>.sentinelone.net/api/addEvents" \
  -d '{"token":"<YOUR_KEY>","session":"ocean-test","events":[{"ts":"'"$(date +%s)000000000"'","sev":3,"attrs":{"event_type":"test","message":"hello"}}]}'
A successful response is HTTP 200 with {"status":"success", ...}. A 404 usually means the path is wrong (must end in /api/addEvents); a 401/403 means the key isn’t valid or lacks write scope.

Configure the destination in Ocean

1

Open the SIEM section

In the Ocean Portal, navigate to Integrations and find the SIEM section.
2

Connect SentinelOne

Click Connect on the SentinelOne card.
3

Fill in the basics

FieldValue
NameA friendly name (e.g. SOC SentinelOne Prod).
URLThe full addEvents URL you assembled above (https://xdr.<region>.sentinelone.net/api/addEvents).
Write TokenThe Write API Key you copied above. Ocean stores this encrypted; it is never displayed again.
4

Pick events to forward

Under Events to forward, select at least one:
  • Inbound Protection — malicious cases
  • Inbound Protection — spam cases
  • AI Response — report phishing
  • AI Response — quarantine release
  • Audit Logs
5

Save

Click Create. Ocean runs a connection test against the endpoint and, on success, starts forwarding within a few minutes.

How events arrive in SentinelOne

Each batch is POSTed as a single JSON object to /api/addEvents. The request body looks like this:
{
  "token": "<write API key>",
  "session": "ocean-<uuid>",
  "sessionInfo": {
    "serverHost": "ocean-security",
    "logfile": "ocean:siem"
  },
  "events": [
    {
      "ts": "1700000000000000000",
      "sev": 3,
      "attrs": {
        "event_id": "...",
        "event_type": "inbound_protection",
        "subject": "URGENT: Wire transfer",
        "verdict": "malicious",
        "sender_address": "alice@example.com",
        "recipient_address": "user@your-org.com",
        "message_internet_message_id": "<CAJ8...@mail.gmail.com>",
        "addressed_to_to": "[\"user@your-org.com\",\"user2@your-org.com\"]",
        "...": "...every other payload field, flattened to a top-level key..."
      }
    }
  ]
}
  • token carries your Write API Key — there is no Authorization header.
  • session is a stable identifier Ocean generates per sender lifetime.
  • sessionInfo.serverHost / sessionInfo.logfile are fixed to ocean-security / ocean:siem so events are always findable and the documented queries (serverHost = 'ocean-security') always hold.
  • Each event uses ts in nanoseconds since the UNIX epoch, encoded as a string.
  • attrs carries event_id and event_type plus the Ocean event payload fully flattened into top-level scalar columns (see below).
  • The Scalyr sev level is always 3 (info). Ocean does not encode the verdict in the lake-level severity — use the verdict field for triage instead.

Field structure: everything is flattened

SentinelOne SDL only exposes top-level scalar fields as queryable columns. Values nested inside objects are stored but are not reliably queryable, so Ocean flattens every event before sending it. The event payload reference describes Ocean’s nested JSON; in SDL that same data arrives flat, transformed by two rules:
  1. Nested objects are flattened with an underscore-joined key. A field at original_email.subject becomes the top-level key original_email_subject; analysis.verdict becomes analysis_verdict; message.internet_message_id becomes message_internet_message_id. When a child key already begins with its parent’s name the duplication is collapsed, so analysis.analysis_reasoning becomes analysis_reasoning (not analysis_analysis_reasoning).
  2. Arrays are sent as a single JSON-encoded string. email.recipients arrives as the key email_recipients with a string value like ["user@your-org.com"]. Query these with contains rather than equality.
  3. Freeform JSON blobs are kept as a single JSON string. Fields whose shape varies per record — the audit-log details, resource_before, and resource_after snapshots — are not flattened. They arrive as one JSON-encoded string so they don’t explode into unbounded, inconsistent per-property columns. Query them with contains.
So the nested overview schema maps to SDL keys like this:
Nested path (overview)SDL flat keyExample value
analysis.verdictanalysis_verdictmalicious
original_email.subjectoriginal_email_subjectAction required: password reset
original_email.sender_addressoriginal_email_sender_addressphisher@malicious.example
email.recipients (array)email_recipients["user@your-org.com"] (JSON string)
reporter.addressreporter_addressuser@your-org.com

Normalized aliases

Because flattening names the same concept differently per event type (verdict for inbound_protection but analysis_verdict for report_phishing / quarantine_release; subject vs original_email_subject vs email_subject), Ocean also adds a small set of normalized aliases to the top level of every applicable event. A single query or detection rule keyed on these covers all event types:
AliasMeaningPresent on
verdictOcean’s verdict (malicious, spam, graymail, safe, …)all
subjectEmail subjectall
sender_addressSender email addressall
recipient_addressRecipient email addressinbound protection
reporter_addressReporter email addressphishing reports
The aliases are additive — the fully flattened keys (analysis_verdict, original_email_subject, …) are still present alongside them.

Querying

Filter on the normalized aliases in PowerQuery — for example, high-signal threats across every event type:
serverHost = 'ocean-security' and verdict = 'malicious'
Scope to one event type and read a flattened field directly:
serverHost = 'ocean-security' and event_type = 'report_phishing' and analysis_verdict = 'malicious'
Match a recipient inside a flattened array (a JSON string) with contains:
serverHost = 'ocean-security' and email_recipients contains 'user@your-org.com'

Defining alerts

Because the high-signal fields are top-level scalars, you can build a Custom Detection Rule (AI SIEM → Detections) directly on them — no parser or mapper required. A rule that fires on any malicious-verdict Ocean email, across all event types:
serverHost = 'ocean-security' and verdict = 'malicious'
Narrow it to a single flow, or combine fields:
serverHost = 'ocean-security' and event_type = 'inbound_protection' and verdict = 'malicious' and attack_type contains 'Credential'
Ocean events ingested over addEvents land in SDL’s All Data tier (third-party ingest), where they are searchable and rule-able as shown above. They do not appear in the agent-only EDR tier, which is populated exclusively by SentinelOne endpoint agents.
See the event payload reference for the full nested schema each flat key derives from.

Troubleshooting

SymptomLikely causeResolution
Destination shows Authentication failedWrong or revoked Write API Key.Re-create the API key in SDL and update the destination.
Destination shows Endpoint unreachableIngest URL is malformed, points at the wrong region, or omits /api/addEvents.Verify the region host and that the URL ends in /api/addEvents.
Connection test fails on createKey lacks ingest permission, or the URL is wrong.Confirm the key is scoped for write ingest and run the curl from the Tip above to isolate the issue.
Events not appearing in SDLIndexing/propagation delay, or events filtered by serverHost/logfile.Wait a few minutes; search without serverHost / logfile filters first.
200 response but a warnings array mentions timestampsThe events landed but were timestamped outside the account’s retention window.This only happens with synthetic / past-dated events; live Ocean events are timestamped at processing time and will not trigger this.
For the full event schema, see the SIEM Forwarding Overview.