The contract
x-exo-concepts index naming the objects that make Exo different from a vector store. It is curated rather than dumped, so what is in it is what is supported.
Check it into your repository. Diffing it between releases is the cheapest possible upgrade review, and because /v1 evolves additively, the diff should only ever grow.
Generating a client
The document is plain OpenAPI 3.1, so the standard generators work. These are the commands, not an endorsement: pick whichever fits your build.- Auth. The document declares two equivalent security schemes: the
X-Exo-API-Keyheader andAuthorization: Bearer. Most generators will wire one of them; either is correct. - The subject header.
X-Exo-Subjectis not declared as an operation parameter, so a generated client will not expose it. Add it to your wrapper as a per-call header. See the overview. - Idempotency.
Idempotency-Keyis likewise not a declared parameter. If your wrapper retries automatically, it must send a stable key or the retry is a second write. See Idempotency.
A wrapper worth 20 lines
Most of what an SDK does for you is: attach the key, raise on a problem body, and surface the request id. That is small enough to own.If your client is an agent
For anything running inside Claude Code, the Claude app, Codex or ChatGPT, you do not need a client at all. Exo hosts an MCP server, and the agent calls the API through it.Reading these docs from an agent
Every page here is available as Markdown by appending.md to its URL, and the documentation itself is an MCP server:
When there is an SDK
There will be a published client eventually. When there is, it will be generated from the same document linked above, so anything you build against the contract now keeps working. This page will say so plainly rather than quietly changing.Next
Versioning and stability
Why generating against the contract is safe.
Integrations
Connect an agent instead of writing a client.