OAuth · GitHub source
Merge the pull request and the wiki page follows
With the GitHub source you paste a file's URL into a macro and the Confluence page renders it from that branch, tag or commit. Your READMEs, architecture diagrams, OpenAPI specs and changelogs stay where they are reviewed and versioned, and the wiki stops being a stale transcription of the repo.
Your engineers never "update the wiki afterwards" again
Engineers keep doing what they already do: change the file, open a PR, get it reviewed, merge. The page follows. Nobody is asked to update the wiki afterwards - the step that never happens, and the reason wiki documentation is distrusted.
Your readers see private repositories without repository access
One person authorises GitHub for the macro, and readers see the rendered file with no GitHub account at all. The people who most need the architecture diagram - support, sales engineering, a new joiner in their first week - are usually the ones without repository access, and now they have the diagram.
Your security team gets its own OAuth app, and GitHub Enterprise works
An administrator registers their own OAuth client rather than using ours, with the client authentication method their policy calls for, including client-secret JWT and private-key JWT. A self-hosted GitHub Enterprise instance is registered the same way, with its own base, API, gist and raw URLs.
Every file renders as what it is
A .mmd renders as a diagram, a .puml as UML, an
openapi.yaml as browsable API docs, a .md as formatted
prose, a .csv as a table - repository files and gists alike, and 29 of
the 31 macros take the same source.
GitHub is one of 13 places Macro Pack reads from
One app, one licence, one connection your admin sets up - and 12 more places a page can pull content from, whether that is a page attachment, a Git repository, an S3 bucket or your database.
See every source compared