Skip to content

Events & Changes

Two ingest paths complement full-run ingestion: events (for streaming telemetry you’d rather not assemble yourself) and changes (so Lumni can correlate a new failure with what changed just before it).

If it’s easier to emit raw events as they occur than to assemble a complete run, post them to POST /v1/ingest/events. Lumni buffers and flattens events that share a run/trace id into a normalized run, then runs detectors once the run resolves.

POST /v1/ingest/events
curl -sS https://agentf.lumniverse.com/v1/ingest/events \
-H "authorization: Bearer $LUMNI_API_KEY" \
-H 'content-type: application/json' \
-d '{
"runId": "run_8842",
"events": [
{ "type": "tool_call", "name": "issue_refund", "status": "failed", "error": "502 Bad Gateway" },
{ "type": "model_output", "text": "Your refund has been processed." }
]
}'

Use events when your framework emits a callback per step (for example a LangChain/LangGraph callback handler) and you want to forward each one without holding the whole run in memory.

Regressions have causes, and the cause is almost always something changed. Record deploys and config edits so an investigation can line a new failure up against the change that preceded it.

POST /v1/ingest/changes
curl -sS https://agentf.lumniverse.com/v1/ingest/changes \
-H "authorization: Bearer $LUMNI_API_KEY" \
-H 'content-type: application/json' \
-d '{
"kind": "code",
"ref": "git:9f2c1a",
"summary": "Bumped refund tool to v3 schema",
"at": "2026-07-01T14:02:00Z"
}'

Recognized kind values include:

kindUse it for
codeA deploy / commit that changed agent behavior
runtimeDependency, model, or infrastructure version bumps
policyA guardrail or policy revision (see /v1/ingest/policies)

Policy revisions get their own endpoint, POST /v1/ingest/policies, so the Guardrail Generator and evidence ledger can track exactly which policy version was in force when a run executed. Wire it into whatever process manages your guardrails so every revision is timestamped and attributable.