Skip to main content
All routes are relative to whatever mountPath you configure (default: none, i.e. the runtime expects request.path already stripped). Every route except GET /health requires an authenticated user — resolveUser returning null or throwing responds 401. Routes fall into two trust tiers. Always on routes are scoped entirely to whichever user resolveUser resolves — an end user managing their own chat, threads, files, and memory. Opt-in routes are Project-level admin operations, gated behind capabilities.*, all defaulting to false. See Capabilities for the reasoning and how to enable them safely.

​
Always on — end-user-scoped, no capability flag needed

scope for memory routes is 'user' (default) or 'agent' (agentId then required).

​
Opt-in — Project-level admin surface, capabilities.* gated

A disabled capability’s routes are simply absent from the route table — a request to one 404s (or, where an always-on route shares a path with a different method — e.g. POST /agents while only GET /agents is always-on — 405) rather than 403, so a disabled capability leaks no information about what it would have done.

​
Multipart uploads

For POST /files and POST /knowledge/:id/documents, the runtime itself never touches raw bytes or a specific multipart parser — a framework adapter parses the incoming multipart body and populates RuntimeRequest.file (single file) or RuntimeRequest.files (multiple), plus puts any other form fields (agentId, threadId) on RuntimeRequest.body. See examples/node-handler.ts’s readMultipartBody for the reference implementation used by the package’s own smoke tests.