Update Notion documentation from GitHub changes
A release can change your product while the Notion page explaining it stays the same. This guide follows one outdated claim through Amendary, from the GitHub change to a reviewed update in Notion.
The example: a help page still shows the old API limit
This is an illustrative example, not a customer result. Imagine a GitHub release whose underlying code raises an API limit from 60 to 120 requests per minute. Your Notion help page still tells customers they can make only 60 requests.
Before: “You can make up to 60 requests per minute.”
Proposed correction: “You can make up to 120 requests per minute.”
The useful result is a correction to that claim with evidence from the change. Amendary maintains document content; it does not synchronize GitHub issues or pull-request statuses into a Notion database.
1. Choose the Notion page and its source repo
Connect the source repository and add Notion as a destination from the Pages tab. Share the help page, or its parent, in Notion’s permission picker. If you haven’t connected them yet, follow Getting started first.
In Pages, find the API help page, choose Watch, and map it to the repository that implements the limit. Use the Help centeraudience and the Docs & guides shape for this example. Sharing a page makes it discoverable; watching and mapping it makes it eligible for maintenance checks.
2. Match the check to what customers have received
On Repos, choose GitHub Releases as this repo’s change trigger if published releases represent what your customers receive. Help-center pages follow that trigger during scheduled checks. Publishing a release does not mean the Notion page updates immediately.
To try a recent release, use Replay a recent release on the Home checklist. Pick the mapped repo and release, then inspect the result. A check can legitimately produce no correction if it finds no supported mismatch. For branch, commit and tag options, see Pages & mapping.
3. Review the claim and the evidence
Keep the workspace in review mode for this walkthrough. Open the correction in the Queue and compare the original passage, proposed text, and linked source. In this example, check that 120 is the limit supported by the shipped change and that it applies to the customers described by this page.
Apply the correction when it is accurate, then open the Notion page to verify the result. If the evidence describes a different plan or endpoint, dismiss the suggestion rather than approving an incorrect statement. Review actions and undo are explained in Queue & reviews.
Permissions and limits to keep in mind
- Amendary can only discover Notion pages shared with its integration. If a page is missing, check sharing or use Add by Notion URL.
- Use a source repo that actually supports the page’s claims. Unrelated code changes are not a reason to rewrite the page.
- The trial uses review mode. On a paid plan, an owner can enable automatic application for eligible corrections; some changes still require review.
- This workflow corrects existing prose. Appending dated product updates is a separate document type.
If no update appears
Check that the page is watched, mapped to the right repo, and shared with the integration. Confirm a release exists for the selected trigger, then check the Queue for a correction waiting for approval. See Troubleshooting for missing pages or failed checks. If your documentation lives in the repository, follow Keep GitHub documentation in sync with code instead.