Integration · Updated
GitHub integration for usedocs
Docs go wrong the day a pull request merges and nobody remembers to update the article. The GitHub integration closes that gap: the merge itself starts the docs update, and you approve it in a minute.
TL;DR
Short answer
The usedocs GitHub integration is how your docs keep up with your code. Install the GitHub app on your repository, and every merged pull request and release is checked against your help center. When one changes something an article describes, usedocs proposes the edit with the change attached. A scheduled check compares every live article with the code too.
Overview
usedocs keeps a SaaS help center accurate with two loops, and GitHub drives the first one. After you install the GitHub app and pick a repository, usedocs reads each merged pull request and release. If the change touches behavior an article describes, such as a renamed setting, a new limit, or a changed flow, it opens a proposed edit on that article in Doc health and the shared review queue, with the pull request, the files, and the reason attached. Accepting the edit updates the live article and keeps the old text in version history. Separately, a scheduled check reads each live article against the code and website and flags what no longer matches, which catches drift that never went through a pull request. Nothing is published without approval. Optionally, usedocs can comment on pull requests with the docs impact; that is off by default.
What this integration does
Proposed edits from merged PRs
Each edit shows the pull request, the files involved, and why the article needs to change, so review takes a minute.
Release aware
Releases are read the same way, so a batch of changes becomes a batch of proposed edits.
Scheduled article checks
Live articles are compared with the code on a schedule, and the ones that drifted get a proposed fix.
First drift report
Right after you connect, usedocs reports which articles no longer match the code.
Optional PR comments
Turn on a comment that lists the docs a pull request affects. It is off by default.
Setup
Open Integrations In the dashboard, open Integrations and choose GitHub under Docs and code.
Install the GitHub app Approve the usedocs GitHub app for the repository that holds your product code. It reads code and pull requests; it does not push to your branches.
Read the first drift report usedocs compares your live articles with the code and lists the ones that no longer match, each with a proposed fix.
Review in one queue From then on, merged pull requests and releases add proposed edits to Doc health and the review queue. Approve, adjust, or dismiss.
Limits and plan notes
- Edits are proposed, never published without approval.
- Unlimited PR screening on Growth under fair use.
- PR comments are opt in and off by default.
- Gap drafts can also be published to a docs folder in the repository or to Notion.
Not for you if
Skip this if your product code is not on GitHub, or if a separate docs team already updates the docs inside every pull request with its own review process. The customer loop, drafts from unanswered questions, works without GitHub.
FAQ
What does the usedocs GitHub integration do?
It reads merged pull requests and releases and proposes edits to the help center articles they affect, with the change as evidence.
Does usedocs push to my repository?
No. It reads code and pull requests. Gap drafts can optionally be published to a docs folder you choose.
Does it comment on every pull request?
No. PR comments are opt in and off by default.
What if a change never went through a PR?
A scheduled check compares live articles with the code and proposes fixes for what drifted.
Is GitHub screening limited?
Growth includes unlimited PR screening under fair use.
Do I need GitHub to use usedocs?
No. Drafts from customer questions and the assistant work without it; GitHub adds edits from your code.