API Reference Overview
Purpose and Scope
The API Reference Overview is the orientation page for readers who already understand what they want to build with LlamaIndex and need to find the correct public type, module, or reference family. The official reference index describes the API section as documentation for modules and integrations used in the framework, and it explicitly directs users to navigation or search when looking for classes. In OpenWiki, this page plays the same role: it is not a replacement for every generated class page, but a map from common development tasks to the official reference entry points that define those tasks.
Sources: docs/api_reference/api_reference/index.md
The reference section should be read alongside the conceptual and guide pages. Concept pages explain why an application uses agents, indexes, language models, or embeddings; the API pages show the public surfaces that code imports and subclasses. This distinction matters because LlamaIndex is broad: the same application may load data, embed chunks, build an index, query through a language model, and optionally place those operations behind an agent. The overview therefore groups the official reference around major families instead of asking readers to scan an undifferentiated list of generated documentation pages.
Sources: docs/api_reference/api_reference/index.md, docs/api_reference/api_reference/agent/index.md, docs/api_reference/api_reference/indices/index.md, docs/api_reference/api_reference/llms/index.md, docs/api_reference/api_reference/embeddings/index.md
Relevant Source Files
- docs/api_reference/api_reference/index.md — Defines the root API Reference page and states the intended use of navigation or search to find classes.
- docs/api_reference/api_reference/agent/index.md — Publishes the agent workflow reference page and lists the workflow agent classes, stream and output types, and tool-call records included there.
- docs/api_reference/api_reference/indices/index.md — Publishes the core indices reference entry point for the shared base index abstraction.
- docs/api_reference/api_reference/llms/index.md — Publishes the core language-model reference, including the central language model class and related base types.
- docs/api_reference/api_reference/embeddings/index.md — Publishes the core embeddings reference, including the base embedding abstraction and embedding-model resolver.
System-to-Code Mapping
The root API reference page is intentionally small. Its job is to establish the reference area as the place for module and integration documentation, while the leaf pages use documentation directives to bind rendered pages to Python objects. That shape is important for maintainers: the source of truth for a public class remains the Python module, while the reference markdown decides which members appear in the published API site. When OpenWiki links into this section, it should preserve that model by treating each reference page as a doorway to generated documentation rather than as hand-written prose alone.
Sources: docs/api_reference/api_reference/index.md
The agent reference page maps the agent family to the workflow-based module and exposes both high-level agents and the records that move through their runtime. The listed members include AgentWorkflow, BaseWorkflowAgent, FunctionAgent, ReActAgent, and CodeActAgent for constructing agent behavior. The same page also names AgentInput, AgentStream, AgentOutput, ToolCall, and ToolCallResult, which signals that agent APIs are not only about configuring an agent class. They also include the typed inputs, streaming events, final outputs, and tool execution records that callers must handle when integrating agents into applications.
Sources: docs/api_reference/api_reference/agent/index.md
The indices reference page is much narrower in the supplied source: it points to the shared base index abstraction. That is still a significant entry point because index-specific pages and implementation families hang off the same conceptual contract. In LlamaIndex applications, an index is the object that organizes processed data so retrieval and query interfaces can operate over it. A reader who is comparing vector, keyword, summary, graph, or other index guides should come back to the indices API family when they need the inheritance point, common behaviors, or the boundary between index construction and query-facing adapters.
Sources: docs/api_reference/api_reference/indices/index.md
The language-model reference page maps to the central LLM class and the base language-model types. It also requests inherited members and suppresses source display in the rendered reference, which is a useful documentation signal: readers are expected to inspect the public contract and inherited interface rather than treat one implementation body as the only behavior. In practice, this family is the reference anchor for completion, chat, streaming, tool-calling, and provider-specific language model implementations described elsewhere in the documentation and integration pages.
Sources: docs/api_reference/api_reference/llms/index.md
The embeddings reference page exposes BaseEmbedding and resolve_embed_model. That pairing shows the two most common reader tasks for the embedding layer. The first task is understanding or implementing the base abstraction used by vector indexing, retrieval, and semantic similarity workflows. The second task is resolving configuration into an embedding model that the rest of the framework can use. When a guide says to configure embeddings globally or pass an embedding model into an index, this reference family is where readers should verify the base contract and the resolver entry point.
Sources: docs/api_reference/api_reference/embeddings/index.md
Major API Families
The agent family is the right starting point when an application needs a language-model-powered actor that can choose among tools, produce intermediate events, and return structured results. The listed workflow agent classes cover both generic workflow composition and named agent styles, including function-oriented, ReAct-style, and code-action variants. Because the same reference page includes stream and tool-call result records, implementers should use it for both sides of an agent integration: constructing the agent and consuming what the agent emits while it runs.
Sources: docs/api_reference/api_reference/agent/index.md
The indices family is the right starting point when the reader’s question is about the object created after data loading, parsing, embedding, and storage preparation. Even though a specific application may use a vector store index, a keyword table, or a graph-oriented index, the base index reference is the common conceptual bridge. It helps developers recognize which parts of their code are index construction, which parts adapt the index into a retriever or query engine, and which behaviors are expected to be shared by concrete index implementations.
Sources: docs/api_reference/api_reference/indices/index.md
The language-model and embedding families should be treated as the model layer of the reference. Language models generate, reason, chat, call tools, or synthesize answers. Embedding models transform text or other supported content into representations used for semantic lookup and similarity workflows. These two families often appear together in a retrieval augmented generation application, but they solve different problems. A query engine may use embeddings to find relevant context and then use a language model to write the answer, so both API surfaces must be configured and debugged independently.
Sources: docs/api_reference/api_reference/llms/index.md, docs/api_reference/api_reference/embeddings/index.md
Compact Reference
| Family | Reference target | Exposed names in the supplied source | When to start here |
|---|---|---|---|
| Root API Reference | docs/api_reference/api_reference/index.md | API Reference landing page | Use this when you need the official navigation or search entry point for modules and integrations. |
| Agents | docs/api_reference/api_reference/agent/index.md | AgentWorkflow, BaseWorkflowAgent, FunctionAgent, ReActAgent, CodeActAgent, AgentInput, AgentStream, AgentOutput, ToolCall, ToolCallResult | Use this when building or consuming workflow-based agent runtimes. |
| Indices | docs/api_reference/api_reference/indices/index.md | BaseIndex | Use this when checking shared index behavior or moving from concept pages to index APIs. |
| LLMs | docs/api_reference/api_reference/llms/index.md | LLM and core language-model base types | Use this when configuring, subclassing, or consuming language-model behavior. |
| Embeddings | docs/api_reference/api_reference/embeddings/index.md | BaseEmbedding, resolve_embed_model | Use this when configuring semantic representations or resolving an embedding model. |
The reference pages use documentation directives that name Python modules and members, so the practical workflow is to identify the family, open the generated page, and then inspect the concrete class or type. For example, an agent implementer should not begin by guessing which event object carries a tool result; the agent page names ToolCallResult next to ToolCall and the stream and output records. An indexing implementer should look for the base index contract before comparing specialized index pages. A model integrator should separate language model questions from embedding model questions before debugging provider behavior.
Sources: docs/api_reference/api_reference/agent/index.md, docs/api_reference/api_reference/indices/index.md, docs/api_reference/api_reference/llms/index.md, docs/api_reference/api_reference/embeddings/index.md
Using This Overview in OpenWiki
A good reading path starts from the application problem and then moves to the matching reference family. If the problem is orchestration, tool use, or runtime events, start with Agents Overview and then use the agent API reference for exact class names. If the problem is data organization for retrieval, read Indexes or Vector Store Indexing before opening the indices reference. If the problem is provider configuration or model behavior, read Models, Embeddings, and Settings before using the LLM or embeddings references. This keeps the API section from becoming detached from the workflow that gives each type meaning.
Sources: docs/api_reference/api_reference/index.md, docs/api_reference/api_reference/agent/index.md, docs/api_reference/api_reference/indices/index.md, docs/api_reference/api_reference/llms/index.md, docs/api_reference/api_reference/embeddings/index.md
When maintaining documentation, keep reference pages precise and let guide pages carry narrative examples. The official root page promises thorough module and integration documentation, so OpenWiki should use this overview as a routing layer and not overload it with every provider, method, or integration. Add focused pages when a family needs more explanation, such as Core API, Agent API, Indices API, Storage API, or Instrumentation API. Then link those pages back here so readers can move between conceptual learning, task guides, and generated class documentation without losing the overall map.
Sources: docs/api_reference/api_reference/index.md
Related Pages and Next Steps
After this page, choose the API page that matches the subsystem you are actively coding against. Use Agent API for workflow agent classes and runtime records. Use Indices API for the base index surface and index-family navigation. Use Core API when you need the broader foundational package context. Use Models, Embeddings, and Settings before changing language-model or embedding configuration, then return to the LLM and embeddings references for exact names. If you are still designing the application rather than checking a class contract, start with the overview, starter example, and core concepts pages first.