SecurityTrackr's audit trail can be pulled into a SIEM or log management platform as OCSF 1.5.0 events. The integration is a small, deliberately boring polling loop: authenticate with a SIEM-only token, request the next page, ingest it durably, then save the opaque cursor. This guide covers the connector contract and the failure modes that matter when the audit trail is part of your evidence.

The feed

A pull-based OCSF export

The endpoint is a versioned REST resource:

GET https://app.securitytrackr.com/api/v1/audit-events

It returns ordinary SecurityTrackr audit-log rows translated at response time into OCSF 1.5.0 events. There are no webhooks, no push delivery, and no object-storage drop. Your connector owns the schedule and checkpoint, so the same pattern works with a managed SIEM, a self-hosted collector, or a small scheduled worker.

The feed is available on the Pro plan and is restricted to the SIEM Integration token role. That separation keeps a general purpose observation token from becoming a broad audit export credential.

Step 1

Create a SIEM Integration token

An owner creates the token under Account → API Tokens and selects SIEM Integration. API access is a Pro feature. The role is machine-only: it can call the audit-event feed and verify itself with GET /api/v1/me, but it cannot read or write observations and it cannot be assigned to a human account.

The token is shown once. Put it in the connector's secret store and attach it at the HTTP layer. Do not place it in a dashboard query, a committed configuration file, or an event payload.

Authorization: Bearer sgt_live_<keyId>_<secret>

Step 2

Verify the credential before the first poll

Check the token with the one other route available to the SIEM role:

curl -s https://app.securitytrackr.com/api/v1/me \
  -H "Authorization: Bearer $SECURITYTRACKR_SIEM_TOKEN"

A successful response includes your organisation id and"role": "siem". A 401 means the credential is malformed, revoked, or expired. A 403 withPLAN_REQUIRED means the organisation no longer has Pro access.

Step 3

Poll, ingest, then checkpoint

Start with the oldest retained event:

curl -s "https://app.securitytrackr.com/api/v1/audit-events?limit=500" \
  -H "Authorization: Bearer $SECURITYTRACKR_SIEM_TOKEN"

The response contains an events array, an opaquenext_cursor, and has_more:

{
  "events": [ /* OCSF events, oldest first */ ],
  "next_cursor": "1754049600000_clau0000000000000000000001",
  "has_more": false
}

Ingest the events into the SIEM and commit that batch before persisting next_cursor. On the next poll, echo it back exactly:

GET /api/v1/audit-events?cursor=<next_cursor>

The checkpoint rule

If ingestion fails after the HTTP response arrives, keep the old cursor and retry the same page. Re-delivery is safe when your SIEM deduplicates on metadata.uid. Advancing the cursor first creates silent data loss.

Step 4

Poll every two minutes

The feed allows one request per 110 seconds per token. Set the connector to a two-minute timer and make one request per poll. Each page can contain up to 500 events, which is the throughput lever for both backfill and steady-state tailing.

has_more: true means that another page is waiting for a future poll. It is not an instruction to drain the feed in a loop. A second immediate request receives a rate-limit error. Events also have a short visibility delay so the server can protect a cursor from clock-skew gaps.

The format

Use OCSF and the immutable event id

Every event carries the OCSF envelope, including version1.5.0, the SecurityTrackr product identity, event class and activity, timestamp, status, and actor details when available. The native SecurityTrackr action remains inmetadata.event_code, so detections can match exact actions without depending only on the broader OCSF class.

Field	Type	Meaning
events	array	OCSF 1.5.0 events, oldest first.
next_cursor	string \| null	Opaque checkpoint for the next request.
has_more	boolean	Whether another page is currently available.
gap_possible	boolean?	Present on a stale cursor when retained rows may have been swept.

Configure metadata.uid as the SIEM deduplication key. It is the immutable id of the source audit row, so a replay after a connector restart does not create a second event.

Backfill

Start where you need, recover what you can

A cursor-less first call walks from the oldest retained event. To begin at a chosen point instead, use from:

GET /api/v1/audit-events?from=2026-08-01T00:00:00Z

from and cursor are mutually exclusive. Audit rows are retained for 180 days by default. If a stored cursor points beyond that horizon, the response may includegap_possible: true. Treat it as a warning to investigate whether the connector was offline long enough for events to be swept, not as proof that a gap exists.

Connector checklist

The short version

Create a Pro SIEM Integration token as an owner and store it in a secret manager.
Verify the token with GET /api/v1/me and confirm role=siem.
Poll GET /api/v1/audit-events every two minutes with limit=500.
Ingest each page durably before saving next_cursor.
Echo next_cursor unmodified and deduplicate on metadata.uid.
Handle has_more on the next scheduled poll, never in a tight loop.
Monitor gap_possible and decide how your SOC handles a retention window breach.

The complete parameter and event schema is published in the unauthenticated OpenAPI document at app.securitytrackr.com/api/v1/openapi.json.

← All articles

Connecting a SIEM or log management tool to SecurityTrackr