Skip to main content
This guide explains how to connect SentinelOne to Clarion. Once configured, every threat SentinelOne raises on your chosen site becomes a Clarion alert that agents can triage, investigate, and link to incidents.
Note: Estimated time: 10-15 minutes. You will need Site Admin (or higher) access in SentinelOne, plus access to the Clarion workspace where you want to connect SentinelOne.

​
What you’ll configure

Connecting SentinelOne takes three things:

​
Prerequisites

  • A SentinelOne console with at least one Linux, macOS, or Windows agent enrolled
  • An admin role on the SentinelOne account or site you want to forward
  • Access to the Clarion workspace where you want to configure the integration

​
Step 1 - Connect SentinelOne in Clarion

  1. Open Clarion and go to Integrations → SentinelOne.
  2. Click Connect. Clarion generates the webhook URL and a webhook secret for this workspace.
  3. Copy the webhook URL and secret immediately. The secret is shown only once; if you lose it you’ll have to disconnect and reconnect to generate a new one.
Keep these on your clipboard or paste them into a password manager - you’ll need them in steps 3 and 4.

​
Step 2 - Create a SentinelOne Service User (SOC role)

You can use a personal API token (tied to your user) for testing, but for the actual integration we recommend a dedicated Service User so the token survives if the original creator’s account changes.
  1. In the SentinelOne console: Policies and settings → User management → Service Users.
  2. Click + New Service User.
  3. Fill in:
    • Name: clarion-integration
    • Description: Used by Clarion to enrich and action threats.
    • Scope: prefer Site (the specific site you’re forwarding from) over Account - least privilege.
    • Role: SOC. This grants both read and edit access on Threats, so Clarion can enrich alerts and run response actions (mitigate, isolate, set verdict/status). A custom role with equivalent Threats read/edit access also works. A read-only role (e.g. Viewer) only enriches alerts and cannot action threats.
    • Expiration: set to 1 year; rotate annually.
  4. Save → the console shows the API Token once. Copy it immediately.

​
Step 3 - Paste console URL and API token into Clarion

Back on Clarion’s SentinelOne configure page, fill in Console details:
  • Console URL - your tenant URL, e.g. https://your-tenant.sentinelone.net. No trailing slash.
  • Site ID / Account ID - optional; populated automatically once the first real threat lands but you can pre-fill them if you have them.
  • API token - paste the token from step 2.
Click Save. The page will show API token (stored — leave blank to keep) next to the field on subsequent visits, confirming the token is set.

​
Step 4 - Configure the SentinelOne side

SentinelOne sends webhooks via the Singularity Webhook marketplace app. The built-in Notifications channels (SMTP, Syslog) don’t support arbitrary headers, so the marketplace app is required for auth to work.

​
4a. Install Singularity Webhook

  1. SentinelOne console → Marketplace.
  2. Search for Singularity Webhook.
  3. Install (or Add Configuration if already installed). Scope to the site you want to forward from.

​
4b. Configure Threat Response Action 1

In the configuration screen:
  • Toggle Make Response Actions available as Manual Response Actions from Threats to on (so you can also fire the webhook manually from a threat in the SentinelOne console).
  • Under Advanced, leave Auto-Disable on Unauthorized Error on.
  • Expand Threat Response Action 1:
    • Name: Clarion
    • Description: Forward threats to Clarion
    • Automation Trigger Options: All Threats
    • URL: paste the Clarion webhook URL from step 1.
    • Action: POST
    • Webhook Request Body: switch to Custom (the presets ship without custom headers, so they can’t authenticate).

​
4c. Custom Body

The webhook body only needs the threat ID - Clarion fills in the rest. Paste this as Define custom message body:
Note: Use the ${activity.…} placeholder syntax (braces, not $(…) parentheses). ${activity.threatInfo.threatId} and ${activity.id} both resolve to the threat ID and work equally well.

​
4d. Headers

Set Headers to:
Then scroll down to the Secret variables section:
  • Var1 - Secret variable description: Clarion webhook secret
  • Var1 - Secret variable value: paste the Clarion webhook secret from step 1.
Click Install.

​
4e. Test the connection

In the Threat Response Action 1 view, click Test Connection. SentinelOne should report Status 200 (or 201) - and you should see a corresponding webhook accepted: alert created log line in your Clarion environment.
Note: SentinelOne’s “Test Connection” sends the template with ${activity.…} placeholders unsubstituted (because there’s no threat in scope during the test). A test alert will be created in Clarion with literal-string placeholder values in the payload - that’s expected. A real threat detection produces the resolved payload.

​
Step 5 - Verify with EICAR

The cleanest end-to-end test is the EICAR test file. On any enrolled endpoint:
Within ~1 minute SentinelOne mitigates the file, posts the thin webhook to Clarion, and Clarion calls back to fetch the full threat. You should see an alert titled [SentinelOne] eicar.com — <hostname> in Triage → Alerts, with full description (file path, SHA256, mitigation status, endpoint IP, site name, deep link back to the console).

​
How severity is mapped

SentinelOne’s payload doesn’t include a severity field - only confidenceLevel: "malicious" | "suspicious" | …. Clarion maps it like this: If a custom template ever sends a severity field with Critical/High/Medium/Low/Informational, Clarion uses that directly and ignores the confidence fallback.

​
Troubleshooting

​
webhook rejected: missing authentication header in Clarion logs

The x-webhook-secret header isn’t reaching Clarion. Most common causes:
  • You switched the Singularity Webhook body mode from Custom to a preset; presets drop custom headers.
  • The Var1 value field is blank, while the headers JSON references ${Var1}.
  • The headers JSON has a syntax error and SentinelOne is silently sending no headers.

​
webhook rejected: invalid authentication token

The x-webhook-secret value doesn’t match what’s stored on the Clarion integration. You probably rotated the secret in Clarion (disconnect + reconnect) and forgot to update Var1 in SentinelOne, or vice versa. Reconnect in Clarion and re-paste the new secret into Var1.

​
Alerts are created but with empty fields

The API token is missing, expired, or scoped to the wrong account/site, so Clarion can’t pull the threat details. Regenerate the token in SentinelOne and re-paste it into Clarion’s API token field.

​
${activity.…} placeholders showing as literal text in the alert payload

You’re most likely seeing a Test Connection alert, where placeholders don’t substitute by design - see step 4e. If a real detection also shows the literal ${activity.threatInfo.threatId} string, re-paste the minimal template exactly as shown in step 4c (braces, not $(…) parentheses).

​
Authentication issue occurred while running automated_response_actions. (1) Invalid json value for Body field

SentinelOne validates the Custom Body as JSON at save time, before any substitution. A bare ${activity} or $(activity) is not valid JSON. Only string-position placeholders ("threatId": "${activity.threatInfo.threatId}") work.

​
Why the API token matters

With the minimal body above, the webhook only carries the threat ID - Clarion needs the API token to turn that into a complete alert (threat name, classification, host, file, mitigation status, console link). The same token also lets Clarion run response actions back in SentinelOne (mitigate, isolate, set verdict/status), which is why we recommend the SOC role rather than a read-only one. Without a token, alerts will be sparse, so we strongly recommend configuring one.