reference.langchain.com

LangChain Reference Docs (reference.langchain.com) is the unified API reference site for the LangChain ecosystem. It documents classes, functions, and types across LangChain, LangGraph, DeepAgents, LangSmith, and integrations, with packages browsable in Python, TypeScript, Java, and Go. Use it when you need to look up a specific API surface; use the separate main documentation site when you need guides, tutorials, or conceptual explanations.

What the site covers

The reference spans the whole ecosystem rather than a single library:

• LangChain — core framework packages
• LangGraph — graph-based agent and workflow APIs
• DeepAgents — deep agent APIs
• LangSmith — evaluation and observability APIs
• Integrations — third-party model, store, and tool connectors

Each of these is documented at the level of classes, functions, and types, so the content is organized around code symbols rather than around tasks or narratives.

Reference docs vs. main documentation

The two sites serve different jobs, and the reference site states the split explicitly:

A practical rule: if you already know the name of the symbol you want to call, the reference is the faster destination. If you know the outcome you want but not the API, start with the main docs and come back to the reference to confirm exact signatures.

Language and package coverage

The reference is not Python-only. It lists Python, TypeScript, Java, and Go packages, which matters if you are working in a polyglot stack or porting an implementation between SDKs. You browse by package, then drill into the classes, functions, and types that package exposes.

When it is worth using as your lookup entry point

It is a good primary entry point if:

• You are already inside the LangChain ecosystem and need exact API details.
• You want one place to check APIs across multiple ecosystem projects instead of jumping between separate sites.
• You work across more than one language binding.

It is a weaker fit if you are evaluating whether to adopt LangChain at all, or if you need task-oriented instructions — those live on the main documentation site, not here.

Practical note

The site describes itself as API reference documentation. It does not present pricing or account requirements in the material available, so treat access and any login behavior as something to verify directly on the site rather than assuming it is unrestricted.

OpenAPI-generated API documentation is reference documentation that is produced automatically from an OpenAPI description file rather than written by hand. You write (or generate) a machine-readable specification of your API — endpoints, parameters, request bodies, responses, schemas, and auth — and a documentation tool reads that file and renders a browsable, often interactive reference site. The spec becomes the single source of truth; the docs become a build artifact.

This differs from manually written docs in one fundamental way: with hand-written docs, the prose is the source of truth and the API is described separately. With spec-driven docs, the API description is the source, and every page, table, and code sample is derived from it.

How the workflow actually runs

A typical spec-driven documentation pipeline has five stages:

1. Author or generate the spec. You either write an OpenAPI document by hand (YAML or JSON), or generate it from code annotations, framework metadata, or a design-first editor. Design-first means the spec is written before implementation; code-first means it is extracted from existing code.
2. Validate and lint. The spec is checked against the OpenAPI schema and against style rules — consistent naming, required descriptions, no undocumented 4xx responses, no orphaned schemas.
3. Bundle and transform. Multi-file specs are combined, $ref pointers are resolved, and the document is optionally split into per-tag or per-version outputs.
4. Render. A documentation tool converts the spec into HTML: an endpoint list, a sidebar of operations, parameter tables, response schemas, and a "try it" console.
5. Publish and version. The rendered site is deployed, and each API version gets its own snapshot so consumers can read docs matching the version they call.

Steps 2 through 5 are usually automated in CI. If the spec fails validation, the docs build fails — which is the point.

Spec-driven vs. hand-written documentation

The practical conclusion most teams reach: generate the reference, write the guides. Reference material is repetitive and mechanical, which is exactly what generation is good at. Conceptual explanations, migration notes, and tutorials carry judgment that a spec cannot express.

What you get out of the box

Generated reference pages commonly include:

• An operation list grouped by tag or path, with HTTP method and path.
• Parameter tables showing name, location (path, query, header, cookie), type, required flag, and description.
• Request and response schemas rendered as expandable trees, including nested objects and arrays.
• Authentication details pulled from the securitySchemes section.
• Interactive request consoles that let a reader send a real call from the browser.
• Generated code samples in several languages, derived from the same schemas.
• Multiple output formats, such as a static site, a single HTML file, or a mock server.

Because all of these come from one document, changing a field name in the spec updates the parameter table, the schema tree, and every code sample at once.

Where spec-driven documentation breaks down

Generation is not free. The trade-offs are real:

Spec quality becomes documentation quality. A field with no description produces a table row with an empty cell. A vague summary produces a vague heading. Tools can enforce presence of descriptions via linting, but they cannot enforce that the description is useful.

Customization has limits. If you need a page that does not map to an OpenAPI concept — a conceptual overview, a pricing explanation, a comparison of two endpoints — you write it outside the generator and link to it.

Not everything is expressible. Webhooks, streaming responses, long-polling behavior, and complex multi-step flows are awkward or impossible to describe fully in OpenAPI. Those need prose.

The spec can go stale. If the spec is maintained separately from the implementation, it drifts just like hand-written docs. The mitigation is to generate the spec from code, or to test the implementation against the spec in CI.

Interactive consoles need care. A "try it" button that hits a production API with real credentials is a security and rate-limit problem. Point it at a sandbox, or disable it.

Deciding whether to adopt it

Adopt spec-driven reference documentation if most of these are true:

• Your API has more than a handful of endpoints, or changes frequently.
• You ship client SDKs or code samples in more than one language.
• Multiple teams consume the API and need a consistent, always-current reference.
• You already have, or are willing to maintain, an OpenAPI description.

Stay with hand-written docs, or a hybrid, if:

• Your API is small and stable, and the reference fits on one page.
• Your documentation is mostly conceptual and contains little endpoint-level detail.
• You cannot commit to keeping the spec in sync with the implementation.

A reasonable middle path: generate the reference from the spec, and hand-write the getting-started guide, authentication walkthrough, and error-handling page. Link the two directions so readers can move from concept to endpoint and back.

A minimal starting checklist

1. Produce one valid OpenAPI document for a single API version.
2. Add a linter with rules for descriptions, operation IDs, and error responses.
3. Wire the docs build into CI so a failing spec fails the build.
4. Render the reference and review it as a reader, not as the author.
5. Write the two or three conceptual pages the generator cannot produce.
6. Version the published docs alongside the API version.

The core idea is simple: describe the API once, in a format both machines and humans can read, and let the reference documentation fall out of that description. Everything else — tooling, hosting, interactivity — is a detail on top of that decision.

Integrations appear in LangChain Reference Docs as one of the covered areas of the LangChain ecosystem, alongside LangChain, LangGraph, DeepAgents, and LangSmith. The reference exposes the classes, functions, and types that make up those integrations, so you can look up an integration's API surface in the same place you look up core package APIs. It is an API reference, not a guide: for setup instructions, tutorials, or conceptual explanations, the docs point you to the main documentation site.

What "integrations" means in the reference

The site describes itself as unified API reference documentation for LangChain, LangGraph, Deep Agents, LangSmith, and integrations. That phrasing places integrations in the same catalog as the first-party products rather than in a separate section. Practically, this means an integration's API entries are documented as part of the LangChain ecosystem reference, not as an isolated third-party listing.

The reference is organized around browsing packages and exploring classes, functions, and types across the ecosystem. So the unit you navigate is the package, and within a package you drill into the specific class, function, or type you need.

What you can look up

For an integration, the reference is the place to check:

• The classes an integration package exposes.
• The functions and methods available on them.
• The types used in their signatures and return values.

This is the same granularity applied to the core products, which is useful when you are wiring an integration into a chain or graph and need to confirm an exact method name, argument, or type rather than a high-level workflow.

Language coverage

The reference covers Python, TypeScript, Java, and Go packages. The site's own summary emphasizes browsing Python and TypeScript packages, while the broader description names all four languages. If you work in Java or Go, treat language coverage as something to verify per package rather than assuming every integration is documented in every language.

How integration entries relate to the main LangChain packages

Integration APIs are documented as part of the same ecosystem reference as the core packages. That means:

• You use one reference site to move between core APIs and integration APIs.
• The relationship is by package and by the classes, functions, and types each package defines, not by a separate integration index described on the page.
• The reference does not, per the available description, explain how an integration is meant to be used in a workflow — that belongs to guides and conceptual docs.

When an integration isn't in the reference

If you can't find an integration entry, work through these checks in order:

1. Confirm you're on the reference site and not the main documentation site. The reference covers APIs; the main site covers guides, tutorials, and concepts.
2. Check the language. Coverage spans Python, TypeScript, Java, and Go, but not necessarily every integration in every language.
3. Search by package rather than by product name, since the reference is organized around browsing packages.
4. If it's still missing, the integration may not be documented in the reference at all — fall back to the main documentation site for guidance.

Reference vs. main documentation site

The reference tells you what exists and how it's typed. The main site tells you how to use it. For integration work, you'll typically move between the two: confirm the API in the reference, then follow the guide on the main site.

LangChain Reference Docs covers five product areas — LangChain, LangGraph, DeepAgents, LangSmith, and integrations — and spans Python, TypeScript, Java, and Go packages. It is the unified API reference for the LangChain ecosystem, meaning you can browse classes, functions, and types across all of these products and languages from one place. It is a reference site, not a tutorial site: if you need guides or conceptual explanations, the docs point you to the main documentation site instead.

Products covered

The reference documentation is organized around the following product areas:

If your work touches any of these five areas, the reference is the place to look up exact signatures, class members, and type definitions.

Languages and packages

The reference is browsable across four language ecosystems:

• Python packages
• TypeScript packages
• Java packages
• Go packages

This matters if your stack is not Python-first. You can check whether the class, function, or type you depend on exists in your language's package before committing to an integration approach.

What you can actually browse

Within each product and language, the reference exposes the API surface:

• Classes — constructors, methods, attributes
• Functions — parameters, return types
• Types — type definitions used across the ecosystem

The scope is described as covering the "entire LangChain ecosystem," so the reference is intended as a single entry point rather than one site per product.

How to decide whether this is the right resource

Use LangChain Reference Docs when you:

• Need the exact signature or type of an API you already know you want to use
• Are checking whether a feature exists in your language (Python, TypeScript, Java, or Go)
• Want to compare the API surface of two products, such as LangChain versus LangGraph

Look elsewhere when you:

• Are learning a concept for the first time and need a walkthrough
• Want a step-by-step tutorial or a conceptual overview — the reference explicitly directs you to the main documentation site for guides, tutorials, and conceptual docs

Practical check before you start

Because coverage is split across products and languages, confirm two things first: which product area your task belongs to (for example, LangGraph for graph workflows versus LangSmith for observability), and which language package you are working in. That combination determines which section of the reference is relevant to you. If a class or function you expect is not listed under your language, it may exist only in another language's package or only in a different product area — check both before assuming it is unavailable.

Yes. The LangChain Reference Docs site states that it covers Python, TypeScript, Java, and Go packages, so you can look up API details in any of those four languages. The practical caveat is that the site describes itself as a unified reference for the LangChain ecosystem — LangChain, LangGraph, DeepAgents, LangSmith, and integrations — and the depth of coverage is not guaranteed to be identical across every language and product combination. Treat the language list as the supported set, not as a promise that every class or function exists in all four.

What "browsing packages" means here

The reference is organized around packages rather than around a single flat API index. In practice, you:

1. Pick the language section you work in (Python, TypeScript, Java, or Go).
2. Pick the package within that language.
3. Browse the classes, functions, and types that package exposes.

That structure matters because the same conceptual feature can live in different packages depending on language. If you search for a feature and get nothing, the likely cause is that you are in the wrong language section or the wrong package, not that the feature is missing from the ecosystem.

Does coverage differ by language or product?

The site's own description lists the products it documents — LangChain, LangGraph, DeepAgents, LangSmith, and integrations — and separately lists the languages. It does not claim that each product is equally documented in each language. So the safe assumption is:

If you need a specific class and it is not in your language's section, check whether the product is primarily shipped for another language before concluding the API does not exist.

How to pick the right language section

Choose by the runtime you are actually shipping, not by the language you find easiest to read. The reference exists so you can confirm exact signatures, types, and names for the code you will write. Reading the Python signature to write TypeScript code invites mismatches in argument names and return types.

A quick decision path:

• Writing a Python service or notebook → Python section.
• Building a web app or Node backend → TypeScript section.
• Working in a JVM stack → Java section.
• Working in a Go service → Go section.

When to use the reference versus the main docs

Use the reference when you already know what you want to call and need the exact shape of it — class members, function parameters, type definitions. Use the main documentation site when you are still deciding what to build or how a concept fits together; the reference explicitly points readers to the main site for guides, tutorials, and conceptual docs.

A concrete example: if you know you need to configure a retriever in TypeScript but cannot remember the constructor arguments, the reference is the right stop. If you are instead asking "should I use a retriever or a vector store here," that is a conceptual question and belongs in the guides.

Common snags

• Wrong language tab. The most frequent dead end. Confirm the language selector before assuming a symbol is undocumented.
• Expecting tutorials. The reference is API-level. Narrative explanations live elsewhere.
• Assuming parity. Because the site lists four languages and several products without promising full cross-coverage, verify the specific package you depend on rather than assuming an equivalent exists everywhere.