API & MCP

API overview

Everything eli.ai does in the browser is available over HTTP. One authenticated surface — /api/v1 for REST and /api/mcp for Model Context Protocol — reads and writes the knowledge base, drives agents, runs governed live-data queries, and produces client-ready reports, all under the same per-workspace row-level security as the UI.

PortsProgrammatic surfacesThe capability system this surface belongs to.

Executable surface / REST

One governed engine, exposed through REST

92 documented operations expose the same capabilities the workspace uses — the same key, the same scopes, and the same row-level security behind every one of them.

WorkspacePeople REST APIApplications MCPAgents

a grounded answer over HTTPbash

curl -L -X POST https://eli.ai/api/v1/query \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"question":"Is anything stuck on the Order Platform right now?","includeData":true}'

Start here

Three references, three jobs. The guides below walk each capability end to end with runnable curl; the API console is the exhaustive schema and a live runner in one place — read an operation, then fire it; the OpenAPI document is the machine-readable source both are generated from.

API consoleEvery operation, parameter, and schema, with curl / JavaScript / Python samples — and a Try it panel that sends a real request without leaving the docs.OpenAPI 3.1 documentThe raw /api/v1/openapi.json — feed it to codegen, Postman, or your own client. Public and cacheable.

Task guides

Copy-paste recipes for the things integrators do most. Each ends with the leverage angle — what the capability unlocks beyond the raw call.

Getting startedMint a key, make your first authed call, and learn the workspace-vs-user key rule.Ingest documentsPOST markdown, list/get/update/delete, and watch it become the graph asynchronously.Manage entitiesCurate entities and relations by hand — arbitrary types, coexisting with extraction.Search & askRaw chunks from /search vs a grounded, dual-cited answer from /query — when to use which.Query live dataConnectors + named queries + a run with full provenance — the semantic↔data bridge.Run agentsStart runs over SSE or JSON, inspect steps, resolve approvals, attach feedback.Build reportsGenerate an as-of snapshot deliverable and fetch it back as JSON or PDF.Connect Confluence, SharePoint & SlackCreate a content connector, run the first sync, and let incremental polling keep it current.Build golden setsAuthor concept-anchored eval items, seed graded qrels, and promote failures into permanent tests.Measure & compareRead retrieval + RAGAS + abstention metrics and A/B two configs behind a two-gate significance test.MCP quickstartPoint Claude or any MCP client at your workspace with a one-line add command.

The shape of every request

One base URL, one bearer token, one workspace. A workspace key (eli_sk_) resolves to exactly one workspace; a user key (eli_uk_) spans the workspaces you belong to and picks one with an X-Workspace-Id header. Every key carries a set of scopes, and each endpoint requires one. Full details in Getting started with the API.

Base URL — https://eli.ai/api/v1 (REST) · https://eli.ai/api/mcp (MCP).
Auth — Authorization: Bearer $ELI_KEY on every request.
Scopes — kb:read · kb:write · data:read · data:run · reports:read · reports:write · agents:run · runs:read.
Errors — a small JSON envelope keyed by status. See Errors & rate limits.

Prefer tools over endpoints?

If the consumer is itself an agent, skip the REST choreography: the MCP server exposes the KB, graph, and data layer as native tools under the same key and RLS.