Evaluate multiple sessions in one call
Batch-evaluate existing sessions in a single call. Pick exactly one mode: (a) sessionIds — explicit list of session IDs; (b) versionId — every session attached to that version. Each selected session is evaluated by the same logic as POST /evaluations/fromSession, so the inference results that already live on the session are scored. Unlike POST /evaluations/fromVersion, this endpoint does NOT require a conversation endpoint connection on the version — use it when the inferences already exist (e.g. imported traces). Metric scope: if you send metrics, they are applied to every session. If you do not send metrics, each session is scored only by the metrics of its own originating specification (the spec that produced its test case), never the union of all the product’s metrics. When you send specificationIds, they act as a strict allow-list: a session is evaluated only if its own spec is in the list; sessions whose spec is not listed — and imported sessions that have no spec — are skipped and reported in message. Use POST /evaluations/fromSession for a single session. See Evaluations.
Authorizations
API key authorization. Pass your API key in the Authorization header as a Bearer token. Both new (gsk_*) and legacy (gsk-) API keys are accepted, e.g. Authorization: Bearer gsk_... or Authorization: Bearer gsk-....
Body
Exactly one of sessionIds or versionId is required.
Explicit list of session IDs to evaluate. Mutually exclusive with versionId.
Evaluate every session attached to this version. Mutually exclusive with sessionIds.
"ver_123"
Metrics to evaluate. When provided, these exact metrics are applied to every session and per-specification scoping is bypassed. Optional: if omitted, each session is scored by the metrics of its own originating specification.
Specification IDs used to scope evaluation. If metrics is omitted, this is a strict allow-list: each session is evaluated only when its own originating specification is in the list, using just that spec's linked metrics; sessions whose spec is not listed (and imported sessions with no spec) are skipped. If metrics is also provided, the explicit metrics apply to every session and these specs' metrics are merged in (additive), with no per-session scoping.
Response
Batch evaluation processed
Number of sessions whose evaluations were dispatched successfully. Sessions skipped during per-specification scoping are counted in neither this nor sessionsFailed. A session is skipped when its originating specification is outside the requested specificationIds, or when that specification has no linked metrics (which can happen even with no specificationIds filter). The count of skipped sessions and the reason for each cause are reported in message.
Number of sessions whose evaluation failed.
Total number of Evaluation records created across all successful sessions.
Per-session failure details.
Human-readable summary. Reports how many sessions were evaluated, failed, and skipped during per-specification scoping, naming each skip cause with its own count and reason (outside the requested specificationIds, or no linked metrics), plus any truncation note.
Total sessions matching the request (versionId mode only). When greater than the count actually evaluated the response was truncated to the first 1000 rows; the caller can re-issue the request with explicit sessionIds to cover the remainder. null in sessionIds mode.
True when the version had more sessions than the per-request page limit (1000).