Partner Integration Packages

Purpose and Scope

Partner integration packages are the provider-specific Python distributions that let LangChain applications connect to external model providers, vector stores, tools, retrievers, and related services while still programming against LangChain’s standard interfaces. The practical benefit is that an application can depend on a small package such as langchain-anthropic, langchain-chroma, langchain-deepseek, or langchain-exa for one provider, while continuing to compose those objects with the shared abstractions from langchain-core and the higher-level agent and retrieval APIs. The partner package READMEs are intentionally concise: they identify the package, show the install command, and send readers to the full integration docs and API reference rather than duplicating long guides in the repository.

Sources: libs/partners/README.md, libs/partners/anthropic/README.md, libs/partners/chroma/README.md, libs/partners/deepseek/README.md, libs/partners/exa/README.md

The official integration guidance frames integrations as a core part of the LangChain ecosystem because standard component interfaces make providers discoverable and interchangeable. In practice, this repository reflects that model in two complementary ways. First, maintained partner packages live under libs/partners/ and publish their own installable distributions. Second, core packages expose integration-shaped entry points where a provider or product is part of the LangChain developer workflow, such as loading LangSmith datasets into Document objects or retaining compatibility imports for older chat loader locations. This page explains both the package-level documentation pattern and the source-level contracts visible in the supplied code.

Sources: libs/core/langchain_core/document_loaders/langsmith.py, libs/langchain/langchain_classic/chat_loaders/langsmith.py

Relevant Source Files

• libs/core/langchain_core/document_loaders/langsmith.py — Defines LangSmithLoader, a concrete integration that converts LangSmith dataset examples into LangChain Document instances for retrieval and few-shot workflows.
• libs/langchain/langchain_classic/chat_loaders/langsmith.py — Provides compatibility exports for LangSmith chat loaders by dynamically routing deprecated imports to langchain_community.chat_loaders.langsmith.
• libs/partners/README.md — Gives the partner integration directory’s reader-facing FAQ and links to the primary integration docs and integration API reference.
• libs/partners/anthropic/README.md — Shows the standard README shape for a maintained chat model integration package, including uv add langchain-anthropic and links to provider docs and API reference.
• libs/partners/chroma/README.md — Shows the same package pattern for a vector store integration with Chroma and points to provider documentation.
• libs/partners/deepseek/README.md — Shows the standard package pattern for a maintained DeepSeek integration, including install, conceptual docs, and API reference links.
• libs/partners/exa/README.md — Shows the standard package pattern for a tool or search integration package built around Exa’s web search API.

Partner Package Documentation Pattern

The maintained partner READMEs follow a deliberately uniform reader journey. A developer first sees the distribution name, PyPI status badges, and a quick install command using uv add. The README then answers “what is this?” in one sentence, naming the provider and the component family. For Anthropic and DeepSeek, the package is described as an integration for generative models. For Chroma, it is described as a LangChain integration with Chroma. For Exa, the README is more specific: Exa is presented as a web search API built for AI that returns clean, ready-to-use page content.

Sources: libs/partners/anthropic/README.md, libs/partners/chroma/README.md, libs/partners/deepseek/README.md, libs/partners/exa/README.md

The next important convention is that READMEs are not the complete manual. They point readers to the hosted LangChain docs for conceptual guides, tutorials, and examples, and when available they point to the Python integrations API reference. This split keeps the repository packages focused on installability and source code while preserving a first-party documentation surface for task-oriented usage. The top-level partner README reinforces the same model by directing readers to the provider overview documentation and the integrations API reference, especially when the desired integration is not listed locally.

Sources: libs/partners/README.md, libs/partners/anthropic/README.md, libs/partners/deepseek/README.md

This is also why third-party and maintained packages should not be treated as a single flat catalog. The public contract is the LangChain component interface: chat models behave like chat models, vector stores behave like vector stores, tools behave like tools, and retrievers behave like retrievers. A provider package adds authentication, provider-specific options, and service-specific behavior, but the consuming application should still be able to compose the object with agents, runnables, retrievers, and tracing. The official contribution guidance echoes this: new integrations are expected to be independent PyPI packages, with documentation added so users can discover and use them consistently.

System-to-Code Mapping

The LangSmith document loader demonstrates what an integration looks like when it is part of core developer workflows rather than a standalone provider README. LangSmithLoader subclasses BaseLoader and produces LangChain Document objects from LangSmith dataset examples. Its docstring explains the conversion: example inputs become Document.page_content, and the entire example is preserved in Document.metadata. That shape matters because it lets a LangSmith dataset become a source of few-shot examples, retrieval content, or evaluation-adjacent data without inventing a separate data model.

Sources: libs/core/langchain_core/document_loaders/langsmith.py

The constructor options show the integration boundary in detail. A caller can select examples by dataset_id, dataset_name, or example_ids; request a historical dataset state with as_of; filter by splits, metadata, or a structured filter; control pagination with offset and limit; and decide whether S3 URLs should be inlined. The content_key option lets the loader extract a nested field from example inputs using dot-separated keys, while format_content controls how that extracted value is serialized. If no LangSmithClient is supplied, the loader initializes one from client_kwargs, but it rejects using both a client instance and client initialization kwargs at the same time.

Sources: libs/core/langchain_core/document_loaders/langsmith.py

The classic chat loader module shows another integration-maintenance pattern: compatibility through dynamic import routing. It declares LangSmithRunChatLoader and LangSmithDatasetChatLoader in __all__, but the actual implementations are looked up from langchain_community.chat_loaders.langsmith through create_importer and a DEPRECATED_LOOKUP mapping. That tells maintainers and application developers that older import paths are being preserved while implementation ownership has moved. This compatibility layer is part of keeping integration packages usable across releases without forcing every downstream project to update imports immediately.

Sources: libs/langchain/langchain_classic/chat_loaders/langsmith.py

Compact Reference

Area	Concrete name	What to use it for
Document loading	LangSmithLoader	Load LangSmith dataset examples as Document objects for retrieval or few-shot example workflows.
Dataset selection	dataset_id, dataset_name, example_ids	Select which LangSmith examples are loaded.
Versioning and splits	as_of, splits	Read examples from a dataset version or from named splits such as train, test, or validation.
Content extraction	content_key, format_content	Choose the input field used as page content and serialize it into a string.
Client setup	client, **client_kwargs	Provide an existing LangSmithClient or allow the loader to initialize one, but not both.
Compatibility imports	LangSmithRunChatLoader, LangSmithDatasetChatLoader	Resolve classic chat loader imports through the community package.
Partner install convention	uv add langchain-anthropic, uv add langchain-chroma, uv add langchain-deepseek, uv add langchain-exa	Add a provider-specific integration distribution to an application.

Execution Flow

A typical developer flow starts with the provider or product they need to connect. If they need a maintained provider package, they install the package named in its README, then follow the hosted provider docs for authentication, initialization, examples, and API details. If they are working with LangSmith datasets, they can instantiate LangSmithLoader, choose a dataset and content extraction strategy, and iterate over lazy_load() to produce Document objects. Those documents can then feed retrievers, prompt examples, or indexing flows using the same document abstraction as other loaders.

Sources: libs/core/langchain_core/document_loaders/langsmith.py, libs/partners/anthropic/README.md, libs/partners/chroma/README.md, libs/partners/deepseek/README.md, libs/partners/exa/README.md

For maintainers, the key design constraint is to keep provider-specific details behind a standard LangChain interface and keep user-facing documentation discoverable. Package READMEs should remain short but complete enough to answer install and identity questions. Hosted docs should carry the task-oriented guide, examples, and conceptual context. Compatibility modules, when needed, should make migrations explicit by routing deprecated imports to their new homes rather than silently duplicating implementations. Next, read the provider-specific integration docs for the package you are installing, or review the language model, vector store, retriever, and tool pages to understand the standard contracts that partner packages implement.