index4.ai Docs by

Appearance

index4.ai for developers ​

New to index4.ai and not writing code? Start on the home page instead — upload files in the browser or connect your AI assistant.

index4.ai is an end-to-end context engine, built by POMA AI on PrimeCut. It pairs a structure-aware ingestion pipeline with a managed retrieval layer that emits prompt-ready context — not raw ranked hits — through a single API call. Ingest a document once, then ask index4.ai questions in natural language and it returns an XML + Markdown block you can drop straight into an LLM call or Agent Workflow.

In the language of the wider market, index4.ai is a managed RAG backend — more specifically, a managed context engine: the complete retrieval pipeline (parsing, structure-aware chunking, embeddings, vector storage, hybrid retrieval with optional reranking, context assembly) behind one managed API, with no vector database or retrieval infrastructure for you to operate. It deliberately stops at retrieval: bring your own LLM — index4.ai does not perform the generation step or require a chat application. How the category works: RAG as a Service explained.

The API lives at https://api.index4.ai/v1; the interactive API reference is at api.index4.ai/docs.

index4.ai is the recommended path when you want to skip the work of managing a retrieval stack and focus on your main product.

What you get ​

CapabilityWhat index4.ai does for you
IngestionParses, chunks, embeds and persists documents into the project's vector + storage namespace.
Hybrid retrievalRuns hybrid (lexical + semantic) search across that namespace.
Context assemblyWraps hits in <doc> tags, applies sandwich ordering, drops a […] between non-consecutive chunks of the same document, and enforces a token budget.
Per-doc filteringRestrict retrieval to a single document with doc_filter — useful for "chat with this PDF" UX.
Document adminList, inspect, and delete documents inside your namespace without touching the vector store directly.

Why a context engine, not a vector DB ​

A vector database returns chunks. An LLM call needs context: ordered, deduplicated, skip-aware, budgeted. Doing that translation layer well is the bulk of every production RAG project. index4.ai does it once, server-side, and ships the formatted block back to you. That means:

  • No reranker code. Hits are already filtered by min_relevance and ordered for prompt locality.
  • No token-budget arithmetic. Set target_tokens for the answer size you want; index4.ai admits the best hits (sandwich-aware) until the block fits.
  • No "where did this answer come from" gap. Each <doc> block is tagged with the source document id, so citations are trivial.
  • No duplicate ingestion logic. Chunking and indexing happen server-side in one pipeline; you never assemble or tune it yourself.

The shape of the workflow ​

text
[your file] ──▶ POST /ingest ──▶ {job_id}
                                    │
                                    ├── poll  GET /jobs/{job_id}/status
                                    └── stream GET /status/v1/jobs/{job_id}   (SSE)
                                                 │
                                                 ▼ (status: done)
[your query] ──▶ POST /search ──▶ { context: "<doc>…</doc>" }
                                    │
                                    ▼
                           drop into LLM prompt

There is no separate "create index" step and no embedding model to choose — index4.ai manages that for you behind the project namespace.

Pages in this section ​

Use index4.ai from an MCP client ​

Want index4.ai inside Claude Code, Claude Desktop, or Cursor? Use the index4ai-mcp server — a hosted MCP endpoint at https://mcp.index4.ai (OAuth login or an API key in a header; nothing to install). It exposes tools for ingest, search, document listing, attributes, jobs status and projects.

See also ​