SDK and Integration Guides

Overview

Documint keeps your documentation in sync with your source code. It works by:

1. Parsing source file ASTs (via tree-sitter) to extract symbol signatures.
2. Comparing those signatures against your documentation.
3. Detecting drift when code changes are not reflected in docs.
4. Generating AI-drafted patches to fix the drift.
5. Opening GitHub pull requests with the fixes.

This guide walks through the full workflow from installation to CI integration.

Installation

pip install documint-mcp

Requires Python 3.11+. This installs three commands:

Product surfaces

Documint exposes several surfaces for different workflows:

First scan

1. Initialize your project

Log in and connect your repository:

documint login
documint projects create --name "My API" --repo "acme/my-api"

2. Run a drift scan

documint scan

This compares your source code signatures against your documentation and reports any drift. The scan uses tree-sitter to parse source files in Python, TypeScript, JavaScript, Rust, Go, Java, and C++ and extracts function signatures, class definitions, and exported symbols.

3. View findings

documint drift

Each finding includes:

• Severity: high (breaking changes), medium (additive changes), low (cosmetic)
• Summary: Human-readable description (e.g., "add_memory() gained a new required parameter ttl not documented")
• Changed symbols: List of functions/classes that changed
• Suggested actions: What documentation needs updating

Understanding drift findings

Documint classifies drift into three severity levels:

High severity (breaking changes)

A public API signature changed in a way that could break existing consumers. Examples:

• Required parameter added
• Parameter removed
• Return type changed
• Function removed

These findings should be addressed before any release.

Medium severity (additive changes)

New functionality was added but not documented. Examples:

• New optional parameter added
• New function or class exported
• New endpoint added

These findings are important for developer experience but do not break existing code.

Low severity (cosmetic)

Minor signature changes that are unlikely to affect consumers. Examples:

• Default value changed
• Type hint refined
• Internal refactoring that changed a symbol name

Generating patches

Via the CLI

documint patches propose

This triggers the 4-step AI patch chain:

1. Structured diff report -- Haiku analyzes the symbol-level diff
2. Stale section detection -- identifies which doc sections need updating
3. Surgical patch generation -- Sonnet writes the minimal documentation fix
4. Verification -- Haiku validates the patch against the source

The generated patch includes:

• preview_markdown -- the full updated documentation
• summary -- what changed and why
• confidence_score -- 0.0 to 1.0
• citations -- source files referenced

Via MCP (AI agent)

If you are using Documint through an MCP-connected agent (Claude Code, Cursor, etc.), the agent calls documint_get_patch and presents the preview for your approval.

Via the API

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  https://api-production-285b.up.railway.app/projects/proj_abc/findings/finding_xyz/patch

Reviewing and approving patches

Review the preview

Always review the generated patch before approving:

# CLI
documint patches propose

# The CLI shows a diff preview. Review carefully before proceeding.

Via the dashboard, navigate to /app/projects/:projectId/patches/:patchId to see the full preview with syntax highlighting.

Approve and create a PR

# CLI -- after reviewing the patch
documint publish

Via MCP, the agent calls documint_approve_patch which creates a GitHub pull request targeting your default branch.

The PR includes:

• The documentation fix as a commit
• A description linking back to the drift finding
• Source citations for traceability

CI integration

GitHub webhook (recommended)

Install the Documint GitHub App on your repository. Once connected, Documint automatically:

1. On push: Extracts changed files from commits and runs a scoped drift check.
2. On pull request: Triggers a full artifact drift evaluation and creates a GitHub Check Run with inline annotations.
3. On release: Triggers drift evaluation before the next publish.

Set up the webhook:

1. Call GET /integrations/github/app to get the required events and permissions.
2. Create the GitHub App with the listed configuration.
3. Set the webhook URL to https://api-production-285b.up.railway.app/integrations/github/webhooks.
4. Install the app on your repository.
5. Verify deliveries are creating drift runs.

CI pipeline (manual)

Add Documint to your CI pipeline to fail builds when documentation drift is detected:

# .github/workflows/docs-check.yml
name: Documentation Drift Check
on: [pull_request]

jobs:
  drift-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install Documint
        run: pip install documint-mcp

      - name: Check for drift
        env:
          DOCUMINT_API_KEY: ${{ secrets.DOCUMINT_API_KEY }}
        run: documint scan --fail-on-drift

Watch mode

For continuous development, run Documint in watch mode to detect drift as you code:

pip install "documint-mcp[watch]"
documint scan --watch

This uses watchdog to monitor source files and re-runs drift detection when changes are detected. Useful for:

• Local development loops where you want immediate feedback
• Keeping documentation in sync during active development
• Catching drift before it reaches CI

Operator dashboard

The hosted operator dashboard provides a visual interface for the full documentation loop:

The dashboard reports live api vs fallback data in the UI, which is the fastest way to confirm whether the deployed frontend is connected to the backend.

Local development workflow

The quickest local self-test:

npm run dogfood

This boots both the API and web services, drives the webhook loop, checks /runtime, and confirms the dashboard is reading from the live API.

For manual local development:

# Terminal 1: Start the API
documint-server

# Terminal 2: Start the web dashboard
cd apps/web && npm run dev

# Terminal 3: Run a scan
documint scan

GitHub App setup

Use the backend manifest route as the source of truth when configuring the GitHub App:

1. Call GET /integrations/github/app to get required events and permissions.
2. Create the app with the listed configuration.
3. Set the returned webhook URL.
4. Install the app on your repository.
5. Verify deliveries are creating drift runs before turning on publish automation.

Deployment

The dashboard reads DOCUMINT_API_URL and remains thin because the backend owns drift detection, traceability, and publish previews.

The backend persists workspaces, projects, findings, patches, PR records, publishes, hosted pages, and activity events in the control-plane database.

Next steps

• MCP Reference -- configure AI agents to use Documint tools
• API Reference -- full REST endpoint documentation
• Self-Hosted Setup -- run Documint on your own infrastructure