Accessible documentation is a vital part of LangChain. We welcome both new documentation for new features/integrations, as well as community improvements to existing docs.
We generally do not merge new tutorials from outside contributors without an acute need.
All documentation falls under one of four categories:

Conceptual guides

Explanations that provide deeper understanding and insights

References

Technical descriptions of APIs and implementation details

Tutorials

Lessons that guide users through practical activities to build understanding

How-to guides

Task-oriented instructions for users who know what they want to accomplish

​
Getting started

​
Quick edit: fix a typo

For simple changes like fixing typos, you can edit directly on GitHub without setting up a local development environment:
Prerequisites:
  • A GitHub account
  • Basic familiarity with GitHub’s web interface for pull requests
1

Find the page

Navigate to any documentation page and click the “suggest edits” link at the bottom
2

Fork the repository

GitHub will prompt you to fork the repository to your account. Make sure to fork into your !
3

Make your changes

Correct the typo directly in GitHub’s web editor
4

Commit your changes

Click Commit changes... and give your commit a descriptive title like fix(docs): description
5

Create pull request

GitHub will redirect you to create a pull request. Title it like docs: Fix typo in X and follow the PR template checklist
Docs PRs are typically reviewed within a few days. Keep an eye on your PR to address any feedback from maintainers.

​
Full development IDE setup

For larger changes or ongoing contributions, set up a local development environment. Our documentation is built using Mintlify, which offers local preview and live reload as you edit.
1

Local repo

Clone our documentation repository unless you plan to update API references only, in which case you can fork the relevant repo (e.g. langchain or langgraph)
2

Mintlify knowledge

Review the Mintlify documentation for component usage and best practices - you can also refer to existing docs for examples
3

Build system & development environment

Set up your development environment following our the steps below
This repository includes configuration files to ensure consistent formatting across different editors:
Settings in .vscode/settings.json are automatically applied when you open the project. No additional setup required.Recommended extensions:When you open the “Extensions” tab in VSCode, it may prompt you to install these extensions automatically.

​
Build system

Only edit files in src/ - The build/ directory is automatically generated!
Our documentation uses a build pipeline that allows us to write in MDX and use Mintlify components. The source files are in src/ and the built output is in build/. You are able to run a local development server with hot reload to see changes in your browser immediately.
1

Install dependencies

You will need to install uv and mint if you haven’t already. Also, be sure to clone the docs repository
cd docs
uv venv
source .venv/bin/activate
uv sync --all-groups
npm i -g mint
2

Start development server

Run from the project root:
docs dev
This starts a development server with hot reload at http://localhost:3000 (unless overridden).
3

Make your changes

Edit files in src/ and see changes reflected immediately in your browser

​
Documentation types

Where applicable, all documentation must have translations in both Python and JavaScript/TypeScript. See our localization guide for details.

​
Conceptual guides

Conceptual guide cover core concepts abstractly, providing deep understanding.
  • Understanding-focused: Explain why things work as they do
  • Broad perspective: Higher and wider view than other types
  • Design-oriented: Explain decisions and trade-offs
  • Context-rich: Use analogies and comparisons
  • Explain design decisions - why does concept X exist?
  • Use analogies and reference alternatives
  • Avoid blending in too much reference content
  • Link to related tutorials and how-to guides
  • Focus on the “why” rather than the “how”
Example pages

​
References

References contain detailed, low-level information describing exactly what functionality exists and how to use it.
  • Information-focused: Describe what exists
  • Comprehensive: Cover all parameters and options
  • Structured: Organized systematically
  • Authoritative: The definitive source for technical details
  • API references: Auto-generated from code docstrings
  • Integration guides: Manual documentation for specific providers/tools
  • Configuration references: Detailed parameter specifications
  • Schema documentation: Data structure and format specifications
  • API references: Update docstrings in source code repositories
  • Integration guides: Create/edit .mdx files in the docs repository under /src/
  • Manual references: Edit existing pages
  • Integration consistency: Follow existing patterns for provider-specific documentation
  • Code examples: Include both basic usage and common edge cases/failure modes
  • Version compatibility: Note when features require specific versions
Existing references When to create new reference documentation:
  • New integrations or providers need dedicated reference pages
  • Complex configuration options require detailed explanation
  • API changes introduce new parameters or behavior
  • Community frequently asks questions about specific functionality

​
Writing standard

​
Mintlify components

Use appropriate Mintlify components to enhance readability:
  • <Note> for helpful supplementary information
  • <Warning> for important cautions and breaking changes
  • <Tip> for best practices and advice
  • <Info> for neutral contextual information
  • <Check> for success confirmations

​
Page structure

Every documentation page must begin with YAML frontmatter: 
---
title: "Clear, specific title"
---

​
Localization

All documentation must be localized in both Python and JavaScript/TypeScript when possible. To do so, we use a custom in-line syntax to differentiate between sections that should appear in one or both languages: 
:::python
Python-specific content. In real docs, the preceding backslash (before `python`) is omitted.
:::

:::js
JavaScript/TypeScript-specific content. In real docs, the preceding backslash (before `js`) is omitted.
:::

Content for both languages (not wrapped)
We don’t want a lack of parity to block contributions. If a feature is only available in one language, it’s okay to have documentation only in that language until the other language catches up. In such cases, please include a note indicating that the feature is not yet available in the other language.
If you need help translating content between Python and JavaScript/TypeScript, please ask in the community slack or tag a maintainer in your PR.

​
Quality standards

​
General guidelines

Multiple pages covering the same material are difficult to maintain and cause confusion. There should be only one canonical page for each concept or feature. Link to other guides instead of re-explaining.
Take a less-is-more approach. If another section with a good explanation exists, link to it rather than re-explain, unless your content presents a new angle.

​
Accessibility requirements

Ensure documentation is accessible to all users:
  • Structure content for easy scanning with headers and lists
  • Use specific, actionable link text instead of “click here”
  • Include descriptive alt text for all images and diagrams

​
Testing and validation

Before submitting documentation:
1

Test all code

Run all code examples to ensure they work correctly
2

Check formatting

make lint
make format
3

Build locally

docs build
Verify the build completes without errors
4

Review links

Check that all internal links work correctly

​
In-code documentation

​
Language and style

Use Google-style docstrings with complete type hints for all public functions.
Follow these standards for all documentation:
  • Voice: Use second person (“you”) for instructions
  • Tense: Use active voice and present tense
  • Clarity: Write clear, direct language for technical audiences
  • Consistency: Use consistent terminology throughout
  • Conciseness: Keep sentences concise while providing necessary context

​
Code examples

Always test code examples before publishing. Never include real API keys or secrets.
Requirements for code examples:
1

Completeness

Include complete, runnable examples that users can copy and execute without errors
2

Realism

Use realistic data instead of placeholder values like “foo” or “example”
3

Error handling

Show proper error handling and edge case management
4

Documentation

Add explanatory comments for complex logic
Example of a well-documented function: 
def filter_unknown_users(users: list[str], known_users: set[str]) -> list[str]:
    """Filter out users that are not in the known users set.

    Args:
        users: List of user identifiers to filter.
        known_users: Set of known/valid user identifiers.

    Returns:
        List of users that are not in the known_users set.

    Raises:
        ValueError: If users list contains invalid identifiers.
    """
    return [user for user in users if user not in known_users]

​
Getting help

Our goal is to have the simplest developer setup possible. Should you experience any difficulty getting setup, please ask in the community slack or open a forum post.
You now have everything you need to contribute high-quality documentation to LangChain!