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.
This route requires the write 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.
A dependency is temporarily unavailable. Safe to retry.
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.
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 to job.completed.
Send Idempotency-Key on every retry path. With the same key and the same body you get the original jobId back instead of a second copy of the content in the graph. See Idempotency.
The job result tells you what the content became.nodesCreated, edgesCreated and domainsDetected come back on the finished job, not on the accept.