SDK and Integration Guides

How the thin hosted site, dashboard, and IDE-facing surfaces fit together for the first Documint release.

Product surfaces

• / is the positioning and onboarding surface.
• /docs is the published documentation surface.
• /app is the operator view for drift checks, traces, and previews.

Integration shape

Documint V1 is not a full CMS. It is a repo-native layer that:

1. reads documentation from the repository,
2. computes artifact traces from source files,
3. detects drift when source moves ahead of docs,
4. creates a reviewable patch preview,
5. publishes a verified docs view.

IDE path

The IDE-facing workflow is intentionally narrow in V1:

• ask for the trace behind a page,
• run a drift check,
• request a proposed patch,
• review the suggested update before it becomes a PR.

The repository remains the source of truth through the whole flow.

Deployment path

• Vercel serves the public product at documint.xyz from apps/web.
• Railway runs the Python backend from the repository root and the root Dockerfile.
• The dashboard reads DOCUMINT_API_URL and can stay thin because the backend owns drift, traceability, and publish previews.
• /app explicitly reports live api versus fallback data, which is the fastest way to confirm whether the deployed UI is talking to the backend.
• pnpm dogfood is the quickest local self-test because it boots both services, drives the webhook loop, checks /runtime, and confirms the dashboard is on the live API path.

GitHub App setup

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

1. call GET /integrations/github/app,
2. create the app with the listed events and read permissions,
3. set the returned webhook URL,
4. install it on the repo,
5. verify deliveries are creating drift runs before turning on publish automation.