Ingest content
Ingestion
Ingest content
Enqueue a single piece of content for ingestion and return immediately with a job id.
POST
Ingest content
Enqueue a single piece of content for ingestion and return immediately with a job id. A background worker chunks it, embeds it and links it into the knowledge graph; poll
GET /v1/ingest/{job_id}/status for progress.
The job is scoped to the effective subject (the API key owner by default, or the subject named by X-Exo-Subject). Send an Idempotency-Key header to make the accept replay safe: retrying with the same key and body returns the original job id instead of enqueuing a second copy.
Authorization
This route requires thewrite 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
Beyond the shared statuses, this route can answer with
idempotency_in_flight, idempotency_key_reuse. 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.
Notes
- Ingestion is async-accept. A 202 means the job is durably queued, not that the content is in the graph. Poll
GET /v1/ingest/{job_id}/status, or subscribe tojob.completed. - Send
Idempotency-Keyon every retry path. With the same key and the same body you get the originaljobIdback instead of a second copy of the content in the graph. See Idempotency. - The job result tells you what the content became.
nodesCreated,edgesCreatedanddomainsDetectedcome back on the finished job, not on the accept.
Authorizations
An Exo API key (exo_...) sent as the X-Exo-API-Key header.
Body
application/json