REST API + native MCP server. Permission-scoped keys. Read or write any board the key has access to.
Every connector endpoint is auth-scoped by the X-API-Key header. A key carries
read, write, or read_write scope, and only sees the boards
you grant it. The Orchestrator processes every accepted write — classify, dedupe, route, embed.
Validate the API key and inspect its scope. Returns connector name, scope, accessible board count, writable board count, and last-used timestamp. Call this once on startup to fail fast on a missing or revoked key.
Details
List every board this key can access. Each board reports id, name, description, role, entry
count, and read/write capability. Pass ?writable_only=true to filter to boards the
key can write into.
Search boards by topic or keywords. Returns the most relevant accessible boards with a
match_score and match_reason. Useful before a deterministic write when
the AI app needs to choose a board itself. Query: ?q=…, ?limit=,
?writable_only=.
Read context entries from a specific board. Pass ?board_id= plus an optional
?query= for semantic ranking. Returns ranked entries with short summaries optimised
for a prompt-context budget.
Search context across all boards the key can read. Pass ?query= and
an optional ?limit=. Each result includes the source board so a reading AI can tell
which memory came from where.
Auto-route a memory blob to the right board(s). The simplest write — no board id needed. INDEX
ranks writable boards, applies its relevance gate, and writes accepted memories through the
normal Orchestrator pipeline. Optional topic_hint nudges routing.
curl -X POST https://api.your-deployment.example/api/v1/connector/capture \
-H "X-API-Key: idx_REPLACE_ME" \
-H "Content-Type: application/json" \
-d '{
"content": "London prefers Ableton Live for music production and recently bought a Push 3.",
"topic_hint": "music production"
}'
Write a memory entry into a specific board. Use when the AI app already has the board id — deterministic, no routing inference. The Orchestrator still runs dedupe and embedding before the entry lands.
curl -X POST https://api.your-deployment.example/api/v1/connector/write \
-H "X-API-Key: idx_REPLACE_ME" \
-H "Content-Type: application/json" \
-d '{
"board_id": "brd_01HX...",
"content": "User finalised the Q2 launch checklist in this conversation.",
"source_label": "ChatGPT · Pro"
}'
Every connector request needs a key. Send it on the X-API-Key header. Keys carry an
explicit scope (read, write, read_write) and a board allow-list
— endpoints refuse calls that exceed either.
To create a key: sign in, open the dashboard, then go to Connectors. The raw key is shown once. Treat it like a password — if it appears in a chat log or shell history, revoke it and generate a new one.
curl https://api.your-deployment.example/api/v1/connector/me \ -H "X-API-Key: idx_REPLACE_ME"
Index ships a stdio MCP server for Claude Desktop, Cursor, and any MCP-capable client. No REST integration needed — the same boards, keys, and Orchestrator pipeline, exposed as native tool calls.
{
"mcpServers": {
"index-memory": {
"command": "/path/to/INDEX/BACKEND/.venv/bin/python",
"args": ["/path/to/INDEX/CONNECTORS/mcp/index_mcp_server.py"],
"env": {
"INDEX_CONFIG_FILE": "~/.index/mcp.env"
}
}
}
}
Import /api/v1/connector/openapi.json into Postman, Insomnia, or any
OpenAPI-compatible client. The schema covers only connector-key-authenticated operations — user
admin routes are excluded.
curl https://api.your-deployment.example/api/v1/connector/openapi.json > index-connector.json
Pull the operation list straight from this deployment's running backend. No external tooling — the page renders the result inline.
The dashboard keeps day-to-day work focused on boards, connectors, and suggestions. Webhooks, usage analytics, and data export live here as documentation-adjacent tools.