> ## Documentation Index > Fetch the complete documentation index at: https://docs.galtea.ai/llms.txt > Use this file to discover all available pages before exploring further. # 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](https://docs.galtea.ai/concepts/product/version/session/evaluation). ## OpenAPI ````yaml https://api.galtea.ai/openapi.json post /evaluations/fromSessions openapi: 3.0.0 info: version: 1.0.0 title: Product Management Service API description: API documentation for Product Management Service contact: name: Galtea AI servers: - url: https://api.galtea.ai security: - bearerAuth: [] tags: [] externalDocs: description: Galtea Platform Documentation url: https://docs.galtea.ai paths: /evaluations/fromSessions: post: tags: - evaluations summary: Evaluate multiple sessions in one call description: > 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](https://docs.galtea.ai/concepts/product/version/session/evaluation). operationId: createEvaluationsFromSessions requestBody: required: true content: application/json: schema: type: object description: Exactly one of `sessionIds` or `versionId` is required. properties: sessionIds: type: array description: >- Explicit list of session IDs to evaluate. Mutually exclusive with versionId. items: type: string example: - ses_123 - ses_456 versionId: type: string description: >- Evaluate every session attached to this version. Mutually exclusive with sessionIds. example: ver_123 metrics: type: array description: > 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. items: type: object properties: id: type: string example: metric_123 name: type: string example: Example Name score: type: number example: 0.95 specificationIds: type: array description: > 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. items: type: string responses: '200': description: Batch evaluation processed content: application/json: schema: type: object properties: sessionsEvaluated: type: integer description: > 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`. sessionsFailed: type: integer description: Number of sessions whose evaluation failed. evaluationsCreated: type: integer description: >- Total number of Evaluation records created across all successful sessions. failures: type: array description: Per-session failure details. items: type: object properties: sessionId: type: string error: type: string message: type: string description: > 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. totalSessionsAvailable: type: integer nullable: true description: > 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. truncated: type: boolean description: >- True when the version had more sessions than the per-request page limit (1000). '400': description: > Bad request — malformed input (e.g. both `sessionIds` and `versionId` provided, neither provided, empty `sessionIds`, wrong types) or a `versionId` that exists but has zero sessions to evaluate. content: application/json: schema: $ref: '#/components/schemas/Error' '401': description: Unauthorized content: application/json: schema: $ref: '#/components/schemas/Error' '404': description: > One or more of the requested entities was not found: the `versionId` does not exist or is not visible to the caller, or one or more `sessionIds` do not exist or are not visible to the caller. content: application/json: schema: $ref: '#/components/schemas/Error' security: - bearerAuth: [] components: schemas: Error: type: object properties: error: type: string example: Error type message: type: string example: Error message description securitySchemes: bearerAuth: type: http scheme: bearer description: >- 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-...`. ````