Skip to main content
Seven events ship in v1. Each fires exactly once per state transition; none fan out per-rater. Subscribe to specific types in enabled_events on the endpoint. Use ["*"] to receive everything — recommended only for warehouse-sync integrations.

Envelope

All events share the same outer shape:
request.id traces back to the API request that triggered the event, useful for correlating customer-side and server-side logs.

Per-event payloads

Fires after POST /v1/evaluations returns 201. Payload mirrors the HTTP response.
Fires on every Evaluation.status transition. Reading the current status alone is insufficient — listen for this event if you need to react on Draft → Running distinct from Running → Ended.
Fires once when all queued AutouserRuns reach a terminal state (completed or failed) AND any pending human rating windows close. The single most useful event for “wake up when the eval is done” integrations.
Fires per AutouserRun when it reaches status: completed. If you queued 6 runs (agentCount: 3 × 2 comparisons), expect six events.
Fires when an AutouserRun errors out. A failed run does NOT consume autouser-rating quota, but you may want to alert on it (the design might be unreachable, or the worker might have crashed).
Fires per Rating row insert — humans AND autousers. The single firehose event for warehouse-sync use cases. High volume on busy evals; budget your receiver accordingly.
Fires when an autouser’s rubric is locked via POST /v1/autousers/{id}/calibration/freeze. Downstream pipelines should listen for this before promoting an autouser to production.

Adding new events

New event types are additive — new entries on Autousers-Event-Type, new payload shapes — and ship without a version bump. Build your receiver to ignore unknown event types: