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. langchainjs or langgraphjs).
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.
Example pages

​
References

References contain detailed, low-level information describing exactly what functionality exists and how to use it.
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

​
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!