SIEM Integration

VeraID pushes audit logs to your Security Information and Event Management (SIEM) platform for centralized security monitoring, correlation with other data sources, and compliance reporting. Delivery is a batch push you trigger per integration (see Pushing events); VeraID does not yet forward each audit entry as it is written.

Authentication

The SIEM endpoints take a signed-in VeraID session (the veraid-session cookie the dashboard uses); creating, changing, testing and pushing an integration need an organization owner or admin. An organization API key is not accepted.

Supported Platforms

Platform	Type	Transport	Default Format
Splunk	SPLUNK	HTTPS (HEC)	JSON
Datadog	DATADOG	HTTPS	JSON
Elastic	ELASTIC	HTTPS	JSON
Generic HTTPS (including Sumo Logic)	GENERIC_HTTPS	HTTPS	JSON
Generic Syslog	GENERIC_SYSLOG	Not yet supported	Syslog (RFC 5424)

Caution

A GENERIC_SYSLOG integration can be created, but every delivery to it fails with “Syslog protocol not yet supported”. To reach a syslog collector, put an HTTPS receiver in front of it and use GENERIC_HTTPS with the SYSLOG format.

Supported Formats

Format	Description	Use Case
CEF	Common Event Format	ArcSight, QRadar, and other CEF-compatible SIEMs
LEEF	Log Event Extended Format	IBM QRadar native format
JSON	Structured JSON	Splunk, Datadog, Elastic, Sumo Logic, and custom pipelines
SYSLOG	RFC 5424 Syslog	Syslog collectors and legacy SIEM platforms

Authentication Types

Type	Identifier	Description
API Key	API_KEY	API key sent as a header (e.g., Datadog DD-API-KEY)
Bearer Token	BEARER_TOKEN	OAuth2 bearer token in Authorization header
Basic Auth	BASIC_AUTH	Username and password with HTTP Basic Authentication
None	NONE	No authentication (e.g., internal syslog collectors)

Note

Splunk uses the HTTP Event Collector (HEC) token, which is passed as an API_KEY authentication type with the header name Authorization and value Splunk <token>.

---

Creating a SIEM Integration

API

curl -X POST https://app.veraid.io/api/v1/siem/integrations \
  -H "Cookie: veraid-session=<your session cookie>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production Splunk",
    "type": "SPLUNK",
    "endpoint": "https://splunk.company.com:8088/services/collector/event",
    "authType": "API_KEY",
    "authConfig": {
      "headerName": "Authorization",
      "headerValue": "Splunk abc123-def456-ghi789"
    },
    "format": "JSON",
    "eventTypes": [
      "identity.create",
      "identity.suspend",
      "credential.revoke",
      "credential.rotation_completed",
      "policy.evaluate.credential.read"
    ]
  }'

Response (201 Created; authConfig is never returned):

{
  "integration": {
    "id": "5b7e2c1a-9d4f-4e3b-8a6c-2f1d0e9b8a7c",
    "organizationId": "org_abc",
    "name": "Production Splunk",
    "type": "SPLUNK",
    "endpoint": "https://splunk.company.com:8088/services/collector/event",
    "authType": "API_KEY",
    "format": "JSON",
    "severityFilter": [],
    "eventTypes": [
      "identity.create",
      "identity.suspend",
      "credential.revoke",
      "credential.rotation_completed",
      "policy.evaluate.credential.read"
    ],
    "isActive": true,
    "lastSyncAt": null,
    "lastError": null,
    "createdAt": "2026-03-19T10:00:00.000Z",
    "updatedAt": "2026-03-19T10:00:00.000Z"
  }
}

Request Fields

Field	Type	Required	Description
name	string	Yes	Display name for the integration
type	string	Yes	Platform type: SPLUNK, DATADOG, ELASTIC, GENERIC_HTTPS, GENERIC_SYSLOG
endpoint	string	Yes	URL or host:port of the SIEM collector
authType	string	Yes	Authentication type: API_KEY, BEARER_TOKEN, BASIC_AUTH, NONE
authConfig	object	Yes	Authentication configuration as string values; send {} when authType is NONE
format	string	Yes	Output format: CEF, LEEF, JSON, SYSLOG
eventTypes	string[]	No	Audit actions to forward, matched exactly. Empty (the default) forwards every action. See Event Type Filtering
severityFilter	string[]	No	Stored, but not applied to pushes today. See Severity Filtering
isActive	boolean	No	Defaults to true

---

Platform-Specific Configuration

Splunk

{
  "name": "Splunk HEC",
  "type": "SPLUNK",
  "endpoint": "https://splunk.company.com:8088/services/collector/event",
  "authType": "API_KEY",
  "authConfig": {
    "headerName": "Authorization",
    "headerValue": "Splunk your-hec-token"
  },
  "format": "JSON"
}

Events are sent as Splunk HEC JSON payloads:

{
  "event": {
    "action": "credential.rotation_completed",
    "actorType": "SYSTEM",
    "actorId": "system",
    "resourceType": "credential",
    "resourceId": "cred_abc123",
    "outcome": "SUCCESS",
    "severity": "MEDIUM",
    "metadata": {
      "identityName": "aws-deploy-prod",
      "rotationReason": "scheduled",
      "gracePeriodHours": 24
    }
  },
  "time": 1742382000,
  "sourcetype": "veraid:audit",
  "source": "veraid",
  "host": "app.veraid.io"
}

Datadog

{
  "name": "Datadog Logs",
  "type": "DATADOG",
  "endpoint": "https://http-intake.logs.datadoghq.com/api/v2/logs",
  "authType": "API_KEY",
  "authConfig": {
    "headerName": "DD-API-KEY",
    "headerValue": "your-datadog-api-key"
  },
  "format": "JSON"
}

Sumo Logic

{
  "name": "Sumo Logic Collector",
  "type": "GENERIC_HTTPS",
  "endpoint": "https://collectors.sumologic.com/receiver/v1/http/your-collector-url",
  "authType": "NONE",
  "authConfig": {},
  "format": "JSON"
}

Tip

Sumo Logic HTTP collectors use a unique URL that serves as both the endpoint and authentication. No separate auth configuration is needed.

Elastic

{
  "name": "Elastic SIEM",
  "type": "ELASTIC",
  "endpoint": "https://elastic.company.com:9200/veraid-events/_doc",
  "authType": "BASIC_AUTH",
  "authConfig": {
    "username": "veraid_ingest",
    "password": "your-password"
  },
  "format": "JSON"
}

Generic Syslog

Syslog delivery is not implemented yet: a GENERIC_SYSLOG integration is accepted, but every push to it fails. See the caution under Supported Platforms.

Generic HTTPS

For SIEM platforms not explicitly supported, use the generic HTTPS integration:

{
  "name": "Custom SIEM",
  "type": "GENERIC_HTTPS",
  "endpoint": "https://siem.company.com/api/ingest",
  "authType": "BEARER_TOKEN",
  "authConfig": {
    "token": "your-bearer-token"
  },
  "format": "JSON"
}

---

Severity and Event Type Filtering

Filter which audit entries are forwarded to your SIEM to control volume and relevance. Both filters are top-level fields of the integration, set on create or with PUT.

Event Type Filtering

eventTypes is a list of audit log actions. An entry is forwarded only if its action is exactly one of them: there is no wildcard or prefix matching here (unlike the audit log query’s action=credential.*), so list each action you want. An empty list forwards every action.

{
  "eventTypes": [
    "identity.create",
    "identity.update",
    "identity.suspend",
    "identity.revoke",
    "identity.delete",
    "credential.create",
    "credential.revoke",
    "credential.expired",
    "credential.emergency_rotate",
    "credential.rotation_completed",
    "credential.rotation_failed",
    "policy.create",
    "policy.update",
    "policy.delete",
    "policy.evaluate.credential.read",
    "policy.evaluate.credential.create",
    "jit.request.approved",
    "jit.credential.revealed",
    "mfa.disabled",
    "mfa.account_locked"
  ]
}

Policy decisions are recorded per enforced operation (policy.evaluate.credential.read, policy.evaluate.identity.delete, and so on), so list each one you want. Alerts and policy.violated are not audit actions; to receive them, subscribe a webhook to alert.triggered or policy.violated.

When an integration has eventTypes, they replace the action list in a push request rather than narrowing it.

Severity Filtering

{
  "severityFilter": ["warning", "error"]
}

A log’s severity comes from its outcome: SUCCESS is info, FAILURE is warning, DENIED is error. The field is stored and returned, but the batch push does not apply it today, so every matching entry is sent whatever its severity. To push only failures or denials, pass outcome in the push request instead.

Caution

credential.verify is written every time a credential authenticates, so it can be the largest share of an organization’s audit log. Leaving it out of eventTypes cuts volume sharply, but your SIEM then cannot see failed or anomalous authentication attempts. Rather than dropping it entirely, consider a second integration with "eventTypes": ["credential.verify"] that you push twice, once with "outcome": "FAILURE" (wrong secrets on usable credentials) and once with "outcome": "DENIED" (any attempt on a revoked, expired, IP-blocked or inactive-identity credential).

Pushing events

curl -X POST https://app.veraid.io/api/v1/siem/integrations/{id}/export \
  -H "Cookie: veraid-session=<your session cookie>" \
  -H "Content-Type: application/json" \
  -d '{
    "startDate": "2026-03-19T00:00:00Z",
    "endDate": "2026-03-19T23:59:59Z",
    "outcome": "FAILURE",
    "limit": 1000
  }'

Field	Type	Required	Description
startDate / endDate	string	Yes	Time range, as ISO 8601 date-times in UTC (2026-03-19T00:00:00Z; date-only values and offsets are refused)
actorType	string	No	USER, IDENTITY or SYSTEM
action	string[]	No	Exact actions to send. Ignored when the integration has eventTypes
outcome	string	No	SUCCESS, FAILURE or DENIED
limit	number	No	Most recent entries to send, 1 to 10,000 (default 1,000)

Only organization owners and admins can push, from a signed-in session; an organization API key is not accepted here. The push runs whether or not the integration is active (isActive is not checked). The response reports total, success and errors counts, and lastError when a delivery failed. An invalid body returns 400, a caller who is not an admin 403, and an integration that is not in your organization 404.

---

Testing a Connection

Verify that VeraID can successfully deliver events to your SIEM before relying on it.

curl -X POST https://app.veraid.io/api/v1/siem/integrations/{id}/test \
  -H "Cookie: veraid-session=<your session cookie>"

Response:

{
  "status": "SUCCESS",
  "message": "Test event delivered successfully",
  "details": {
    "endpoint": "https://splunk.company.com:8088/services/collector/event",
    "responseCode": 200,
    "latency": "145ms"
  }
}

If the test fails, the response includes diagnostic information:

{
  "status": "FAILED",
  "message": "Connection refused",
  "details": {
    "endpoint": "https://splunk.company.com:8088/services/collector/event",
    "error": "ECONNREFUSED",
    "suggestion": "Verify that the endpoint is reachable and the port is open. Check firewall rules and network policies."
  }
}

---

Audit Log Export

Besides pushing to an integration, you can export audit logs in bulk for historical analysis or compliance archives.

curl -X GET "https://app.veraid.io/api/v1/audit-logs/export?format=json&startDate=2026-03-01T00:00:00Z&endDate=2026-03-19T23:59:59Z" \
  -H "Cookie: veraid-session=<your session cookie>" \
  -o audit-logs-march.json

Supported export formats:

Format	Content-Type	Description
json	application/json	JSON array of audit log entries
csv	text/csv	CSV with headers, suitable for spreadsheet analysis

An export returns at most the 10,000 most recent matching entries; see Export Audit Logs for the parameters and how to split a longer history. Give endDate as a full date-time: a date alone means midnight at its start, so endDate=2026-03-19 leaves out all of 19 March.

Tip

For continuous forwarding, push to a SIEM integration rather than exporting. Exports need a signed-in session and return at most 10,000 entries each, so an archive built from them must split the history into ranges that stay under that limit.

Event Schema

All events forwarded to your SIEM follow a consistent schema regardless of the output format:

{
  "id": "evt_abc123",
  "timestamp": "2026-03-19T10:30:00Z",
  "action": "credential.verify",
  "actorType": "IDENTITY",
  "actorId": "id_xyz789",
  "actorName": "aws-deploy-prod",
  "resourceType": "credential",
  "resourceId": "cred_def456",
  "outcome": "SUCCESS",
  "severity": "INFO",
  "ipAddress": "203.0.113.42",
  "userAgent": "veraid-sdk/1.2.0",
  "organizationId": "org_abc",
  "metadata": {
    "scopes": ["secrets.read"],
    "endpoint": "/api/v1/secrets/db-url"
  }
}

When using CEF format, the same event is rendered as:

CEF:0|VeraID|Identity Platform|1.0|credential.verify|Credential Verify|2|act=credential.verify outcome=SUCCESS suser=aws-deploy-prod suid=id_xyz789 src=203.0.113.42 deviceCustomString1=credential deviceCustomString2=cred_def456 requestClientApplication=veraid-sdk/1.2.0 end=1773916200000