Keep your Notion help center up to date with GitHub
Your product ships from GitHub. Your help center lives in Notion. Every release can make a sentence on a help page wrong, and nobody re-reads the whole help center after each release. Amendary checks the Notion pages you map against what shipped and drafts the correction with the release attached.
The problem, in your words
A customer follows a help page and the product does the opposite. Support hears about it first. Someone opens Notion, searches for the old number, and fixes the one page they found. The second page with the same claim stays wrong.
Release notes say what changed. They do not say which help pages described the old behaviour. Finding that out means reading pages, and that work gets skipped when the team is busy, which is always.
What happens on a release
- Amendary reads the published release and the code change behind it. GitHub Releases is one change trigger; commits on a branch or new tags work too.
- It checks the mapped help pages. A mapped page is a Notion page you chose to watch and tied to the repository that implements what it describes. Nothing else is checked.
- It looks for the sentence that became wrong. A release that touches nothing a page describes produces no correction. That is a normal result, not a failure.
- It drafts the correction: the old passage, the new text, and the release and summary it worked from. Every version, path and URL in the draft has to be grounded, meaning the change itself backs it up. When an edit cannot be placed on a specific block, Amendary posts a page comment instead of guessing.
- The correction waits in the queue, the list of corrections for your review. You compare the before and after, open the evidence, and apply or dismiss. New workspaces start in review mode. On a paid plan, an owner can turn on auto mode; grounded corrections then apply on their own, while removals, additions and values the change does not back up still wait for a person.
- An applied correction can be undone from Amendary for 30 days. Undo restores the original text after checking that nobody edited the block since.
What it does not do
No new docs host
Your help center stays in Notion. Readers never see Amendary.
No migration
You share the pages you already have with the integration. Nothing is copied anywhere.
Never edits an unmapped page
Sharing a page makes it discoverable. Only watching and mapping it make it eligible for a correction.
Never edits code
GitHub is read for evidence. Writing documentation into a GitHub docs folder or wiki is a separate setting, off by default.
Amendary also does not sync issues or pull-request status into a Notion database, and it does not promise to catch everything. A check finds supported mismatches on the pages you map.
Setup in four steps
- Connect GitHub, then add Notion as a destination from the Pages tab and share the help center, or its parent page, with the integration.
- On Pages, watch each help page and map it to the repository that implements it, with the Help center audience.
- On Repos, choose GitHub Releases as the change trigger if published releases are what your customers receive.
- Replay a recent release from the Home checklist and open the first correction in the queue.
Where to go next
- Update Notion documentation from GitHub changes, the step-by-step walkthrough with an example correction.
- Notion integration: what Amendary reads and edits, and the permissions it asks for.
- GitHub integration: change triggers, and what read access means for your code.
- Pricing: a flat subscription covers daily checks and corrections. Only generating docs from scratch spends credits.
See the first correction on your own docs
Connect GitHub and the docs you already keep in Notion or GitHub. The first check runs on a recent release, so you see a correction with its evidence before you decide anything.
Free for 7 days, no card. You approve every edit. Code is never touched.