Get a job
Fetch one job by id; 404 job_not_found if it is not in the caller’s set.
job_not_found if it is not in the caller’s set.
The canonical, cross-family job view: an import, a session backfill and a
generic ingest all resolve to the same Job shape. status follows the
documented internal->public mapping (done surfaces as succeeded).
Per-user/subject scoped: a job owned by another member is a 404, never a leak
(admin keys see the whole org).
Authorization
This route requires theread scope.
A missing or invalid credential returns 401 authentication_error. A valid credential without the scope returns 403 permission_denied, and the problem body names the exact scope required.
Headers
These are request conventions the contract does not declare as parameters, so they do not appear in the schema tables below.Success responses
Errors
job_not_found. Every problem body names its own code, and the type URI always resolves to the matching page.
Every error is an RFC 9457 application/problem+json body carrying a stable code, a requestId, and a suggestedAction where Exo has one. See Errors.Authorizations
An Exo API key (exo_...) sent as the X-Exo-API-Key header.
Path Parameters
The job id (a UUID) returned by an ingest or import call.
Response
Successful Response
A pollable ingest/import/session job (spec 4.3).
status is one of pending | running | succeeded | failed | canceled
(documented as a string, not a closed enum, so a future internal status
never breaks a tolerant reader). error is the human failure reason,
non-null only on failed. result is the server's interpretation of a
finished job (nodes/edges/domains created), null until the worker reports it.
The server's interpretation of a finished job: what it created.
Populated from the worker's result block in payload_inline once the
job completes; any field the worker did not report stays null.