SIEM Integration

PurpletGo forwards every audit log event to your SIEM in real time, as it is written, plus three revocation and status events with extra detail. Six target types are supported out of the box: Splunk (HTTP Event Collector), Datadog (Log Intake), Elasticsearch (single-document index API), Sumo Logic (HTTP Source), New Relic (Log API), and a generic HMAC-signed webhook for anything else. Splunk and generic targets can take events as JSON or as CEF (Common Event Format).

Why forward events to a SIEM

Offboarding is a high-risk period for data exfiltration and access abuse. Forwarding PurpletGo events to your SIEM lets security teams:

• Correlate offboarding activity with access log anomalies in real time
• Maintain an independent copy of offboarding-related events for compliance audits
• Detect and alert on unusual patterns around access revocation and role changes

Configuring a SIEM target

Navigate to Settings → SIEM Export (a separate settings tab from Webhooks) and click Add Target. Every target needs a name, a type, and an endpoint_url the target's own auth token is sent to - the URL can't point at a loopback, link-local or private-network address, since PurpletGo will be making outbound requests to it on every matching event. The address is checked again each time PurpletGo sends to it, and redirects are never followed: the endpoint must accept the event itself.

When you edit a target, the stored token is never shown. Leave the token field blank to keep it, or enter a new one to replace it.

Delivery behavior

Every event for every target is queued in PurpletGo's database before it is sent, so a restart or a deploy loses nothing. Each delivery is one request; when the collector refuses it, can't be reached or doesn't answer within 10 seconds, PurpletGo tries again later, waiting about 1 minute, then 2, 4, 8 and so on, doubling each time with some random spread, for 12 retries: at least 68 hours in all. A generic target's X-PurpletGo-Delivery id stays the same on every attempt of a delivery, so your receiver can drop a retry it already processed. Events are delivered in the background, so a SIEM outage never blocks or delays the PurpletGo action itself, and deliveries are not guaranteed to arrive in order: use each event's timestamp (or occurred_at for audit events) to order them.

A delivery is given up on when every retry has failed, or at once when retrying can't help: the endpoint is not a public address, the collector answers with a redirect, or it rejects the payload itself (HTTP 400, 413 or 422). A 401, 403 or 404 is retried, so fixing a wrong token or URL within the retry window still delivers what was waiting.

Each target shows its last delivery time and status, the running delivery count, the last error when the last delivery failed, and how many deliveries were given up. A target can be paused and reactivated without deleting it; while it is paused, or the organization is read-only, nothing is queued for it, and deliveries already queued are dropped when their turn comes.

Batch export replays the audit log of a date range to one target: pick the target and the range, and PurpletGo queues the entries, oldest first, up to 10,000 at a time. When the range holds more, choose Queue More to queue the next 10,000 (the API returns a next_cursor to send back). Queued entries are delivered in the background with the same retries, and the target's counts show how it is going. Entries about a former employee whose data was erased are sent with [erased] in place of their name, email address and other personal details (Data retention).

Events

A target receives every event, or only the ones you choose for it.

Every audit log entry is sent in real time, as soon as it is written, with its audit action as event_type (for example login_failed, offboarding_deleted or siem_target.created) and these fields: audit_id, action, target, details, actor_id, actor_name and occurred_at. The list of actions to choose from is in the target dialog, and from the API at GET /api/siem-targets/events. A target you add starts receiving events within 30 seconds; to fill in anything written in those seconds, use Batch export for that time range.

Three events carry more detail than their audit entry:

These are delivered as high severity: access_revoked, revocation_failed, status_changed, offboarding_deleted, member_removed, audit_log_exported, login_failed and checklist_completed. Everything else (like the siem_test event fired by Test) is delivered as info.

Payload format

Every event carries the same base envelope, regardless of target type:

{
  "event_type": "access_revoked",
  "source": "purpletgo",
  "org_id": "9f2b3c1a-...",
  "timestamp": "2025-03-15T09:42:11.000Z",
  "severity": "high"
}

source is always purpletgo. The fields specific to the event are merged into this same object, and what started the event is in trigger:

How that object gets wrapped depends on the target type - Splunk gets it under an event key with HEC metadata, Datadog gets it JSON-stringified into a message field, and so on, as described above.

CEF

With Payload format set to CEF, Splunk and generic targets get each event as one line of ArcSight Common Event Format instead of JSON. A Splunk target receives it as the HEC event with sourcetype: "cef"; a generic target receives the line as the request body (Content-Type: text/plain), HMAC-signed as above. The other target types always take JSON.

CEF:0|PurpletGo|PurpletGo|1.0|offboarding_deleted|Offboarding deleted|7|rt=1790856000000 act=offboarding_deleted cat=high suser=Ann Admin suid=6c1e... externalId=9e1c... cs1=9f2b... cs1Label=orgId cs2=Jordan Lee cs2Label=target msg=...

In the header, | and \ are escaped with a backslash; in values, = and \ are, and a line break becomes \n. Fields an event doesn't have are left out. A SIEM that needs every field of an event uses JSON.

Related pages

• Security and audit log
• Integrations
• SCIM provisioning
• Custom roles