GitHub

OverviewCopy Anchor Link

The GitHub integration does three things:

1. Ticket ingest — new Issues and Discussions become tickets in answerLoops. AI drafts a reply and posts it back as a GitHub comment automatically when confidence is high enough and Automatic Deflections is turned on for that repo (off by default — see per-repo settings). Issues, comments, and discussions authored by anyone with write access to the repo — owners, org members, and collaborators (GitHub's author_association field) — are skipped, so maintainers filing their own work-tracking issues never turn into support tickets or count against your deflection rate.

   Comments on an issue or discussion that already has a ticket are added to that ticket's Conversation instead of opening new tickets, and the AI draft is not posted again. A maintainer's comment on a tracked issue or discussion is kept in the conversation too, labeled Maintainer, without becoming a ticket or notifying anyone. Comments from bots are ignored. A comment on a closed issue joins that issue's ticket too, and reopens the ticket if you had resolved it; a closed issue that never had a ticket is ignored, so a stray comment on an old issue doesn't open one. Comments that were turned into their own tickets before comments were threaded can be folded into their issue's ticket with pnpm github:backfill-threads --org=<id> (add --dry-run to preview). It needs DATABASE_URL and the GitHub App credentials, only touches the organization you name, and leaves any comment ticket that already has replies as it is.

2. Markdown KB sync — markdown files in a repo are embedded into the Knowledge Base. Syncs automatically on every push to the default branch (when enabled) or manually via Sync now. Both queue a background job rather than blocking the request.

3. Discussions KB sync — answered GitHub Discussions become first-class KB articles: the discussion title is the question, the accepted answer is the answer, attributed to the answering user. A discussion syncs the moment it's marked answered, and un-marking an answer removes the article. Sync now also backfills every already-answered discussion in the repo.

PrerequisitesCopy Anchor Link

• A GitHub App created under your account or org
• GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY, GITHUB_APP_SLUG, GITHUB_APP_CLIENT_ID, GITHUB_APP_CLIENT_SECRET, and GITHUB_WEBHOOK_SECRET set in your environment

1. Create a GitHub AppCopy Anchor Link

Go to github.com → Settings → Developer settings → GitHub Apps → New GitHub App.

Under Permissions, set:

• Repository → Issues: Read & write
• Repository → Contents: Read-only (for KB sync)
• Repository → Metadata: Read-only
• Repository → Discussions: Read-only (or Read & write)

Under Subscribe to events, tick:

• Issues
• Issue comments
• Discussions
• Discussion comments
• Push (for automatic KB sync on push)

Save the app. Note the App ID, your App slug (the URL-safe name), and the app's Client ID. Under Client secrets, click Generate a new client secret and copy it.

The user-authorization setting lets answerLoops confirm that the person finishing the install can access the installation before any repository is connected to your org.

2. Generate a private keyCopy Anchor Link

In your GitHub App settings → Private keys → Generate a private key. This downloads a .pem file.

Base64-encode it:

base64 -i your-app.pem | tr -d '\n'

Set the result as GITHUB_APP_PRIVATE_KEY.

3. Set environment variablesCopy Anchor Link

GITHUB_APP_ID=<your-app-id>
GITHUB_APP_PRIVATE_KEY=<base64-encoded-pem>
GITHUB_APP_SLUG=<your-app-slug>
GITHUB_APP_CLIENT_ID=<your-app-client-id>
GITHUB_APP_CLIENT_SECRET=<your-app-client-secret>
GITHUB_WEBHOOK_SECRET=<your-webhook-secret>

4. Install the appCopy Anchor Link

In your answerLoops dashboard, go to Integrations → GitHub → Connect GitHub. This opens the GitHub App install page for your account or org. After authorizing, GitHub redirects back, answerLoops confirms you can access the installation, and your repos are auto-discovered. Only org owners and admins can connect GitHub, and a repository can be connected to one answerLoops org at a time.

5. Configure per-repo settingsCopy Anchor Link

Each connected repo has three controls:

• Monitored events — choose Issues, Discussions, Both, or None. This governs ticket ingest only.
• Automatic Deflections — off by default. While it's off, even a high-confidence answer is held as a draft on the dashboard awaiting Approve/Edit/Dismiss instead of posting as a GitHub comment automatically, and nothing is posted to the issue until your team sends a reply. Turn it on per-repo once you trust the AI's answers going out unsupervised.
• Knowledge Base source — toggle KB sync on/off; Sync now queues a sync

When KB sync is enabled: every push to the default branch queues a re-embed of all .md and .mdx files (pushes to other branches, tags, or PR refs are ignored), and every discussion marked as answered syncs into the KB immediately (independent of Monitored events — a repo can feed the KB from Discussions even if ticket ingest is set to Issues or None). Sync now queues a re-sync of both markdown files and the full set of currently-answered discussions.

Markdown/discussion syncs run in the background rather than inside the webhook or the button click — the KB page shows the job as queued, then syncing, then done, and it's safe to navigate away. Repeated triggers for the same repo while a sync is queued collapse to one job, so a webhook redelivery never starts overlapping syncs. Pushes are spaced out: a push that lands within two minutes of the previous sync finishing is queued to start once that window ends, and a push that arrives while a sync is running queues exactly one follow-up run, so serial pushes never re-embed the repo continuously and the latest content is always picked up.

Each sync builds the replacement for the repo's files and for its Discussions alongside the live content and swaps it in only once it is complete. If a sync fails or a full Knowledge Base leaves no room, the previously synced content stays in place and searchable. If the sync can't import anything at all, it keeps what you have and reports that nothing was imported. A running sync reports a heartbeat; if it stops reporting for several minutes it is picked up again, and the earlier run stops without overwriting the newer one. Every file in a sync is read from one commit, the repository's head when the sync starts, so a push that lands mid-sync cannot mix two versions of your docs. That commit is shown next to the last-synced time as a short link (for example docs at 3f9c2ab), so you can see exactly which version of the docs the knowledge base reflects. Repositories synced before this was recorded show the date alone until their next sync. Failures are shown on the Knowledge Base page in plain language; the technical detail is kept in the server log. Starting a manual sync requires an owner or admin role. When a sync changes documentation, saved resolutions about the same subject show a notice asking you to re-check them; see Knowledge Base.

TroubleshootingCopy Anchor Link