What the export contains
LangWatch writes one OCSF record per trace that arrives through an ingestion source, and one per admin view of a member’s or a team’s workspace (actionName governance.viewWorkspaceAs). Each record is an OCSF 1.1 API Activity event (class_uid 6003, category_uid 6). A record linked to an anomaly alert has severity_id 4 (Medium); every other record has severity_id 1 (Informational).
Records are stored with no expiry. Your SIEM pulls them by cursor, on its own schedule, and keeps its own watermark.
Endpoint and auth
The export is the tRPC query governance.ocsfExport. Call it as a GET on /api/trpc/governance.ocsfExport with the input JSON in the input query parameter.
Output
The HTTP response wraps the procedure result under result.data.json. The result is:
rawOcsfJson is the full OCSF 1.1 event as a JSON string. The other fields are the columns your SIEM filters on. actionName is the tool the trace invoked, or trace.recorded for a trace with no tool call. An organization with no ingestion source yet returns { "events": [], "nextCursor": null, "nextCursorCompound": null }.
anomalyAlertId is returned on every record and is always empty. No attribute sets it, so no exported record is ever linked to an anomaly alert, and severityId is always 1 (Informational). Anomaly alerts are not exported as OCSF rows at all. They are delivered by webhook, described in Anomaly rules.
Persist nextCursorCompound after each page. On the next pull, pass its eventTimeMs as sinceMs and its eventId as sinceEventId. Records are ordered by eventTimeMs ascending.
A page that returns limit records may be followed by more. Pull again at once until a page returns fewer than limit records, then wait for your next scheduled run.
Example
Write the cookie into a curl config file that only the job user can read, and pass the file rather than the value. A -H argument puts the cookie in the process argument list, where every other user on the host can read it out of ps.
mktemp makes a new file each run, owned by the job user and readable only by them. Writing to a fixed path instead would reuse whatever file or symlink is already there, and keep its permissions.
$SESSION_COOKIE is the cookie of a browser session signed in as a user who holds complianceExport:view. Read it from your secrets store into the job environment. The trap deletes the config file when the shell exits, on a failed run as well as a clean one. Forward events[] to your SIEM’s ingest API, then store nextCursorCompound for the next run.
The session cookie is a full browser credential for that user, and this endpoint takes no other credential. It is not scoped to complianceExport:view, and it expires on the session’s own schedule rather than the job’s. Keep it out of shell history, out of the process argument list, and out of any script committed to a repository, and rotate the session when the job host changes.
Also check: Anomaly rules for how a fired alert reaches you, which is by webhook rather than through this export, and Retention for how long the source traces are kept.