Skip to main content
Connect your agent to GitHub to work with your code repositories — browse files, create and review pull requests, manage issues, and react when a pull request is opened.

​
How to enable

Go to Settings → Capabilities and enable GitHub. Then choose how the agent signs in — a personal access token or a GitHub App — and optionally specify which repositories to watch (see below for details).

​
Example use cases

  • Code Review Assistant — “Review PR 254 and flag any potential issues or security concerns”
  • Release Notes Generator — “Summarize all commits since the last release and generate release notes”
  • Issue Triage — “Every morning, go through the issues opened since yesterday and add appropriate labels”
  • Dependency Updates — “Check for outdated dependencies and create a PR with updates”

​
Choose how the agent signs in

  • Personal access token — quickest to set up. The agent acts as the person who created the token, with that person’s access.
  • GitHub App — for organizations that don’t allow personal tokens. The agent acts as the app itself, limited to the app’s permissions and the repositories it is installed on. See Connect with a GitHub App.

​
How to connect with a personal access token

1

Create a personal access token

Go to GitHub Settings → Developer settings → Personal access tokens and create a new token. GitHub offers two types:
On GitHub Enterprise, create the token on your own instance — for example https://yourcompany.ghe.com/settings/tokens — not on github.com. Tokens are not valid across instances. See GitHub Enterprise below.
Fine-grained tokens (recommended) — Create a fine-grained token with for example these permissions:
  • Contents: Read and write
  • Metadata: Read-only (required)
  • Pull requests: Read and write
  • Issues: Read and write
Classic tokens — If you need simpler setup or access across multiple organizations, create a classic token with the repo scope.See GitHub’s documentation on personal access tokens for more details.
2

Configure in Abundly

Go to Settings → Capabilities and enable GitHub. The capability has two cards: Outgoing (API calls) lets the agent call the GitHub API, Incoming (webhooks) wakes it on pull requests. Tick Outgoing (API calls), choose Personal access token as the authentication method, click Add Secret, paste your personal access token, and give the secret a name. The token is encrypted and stored at the workspace level, so other agents can reuse the same secret and you rotate it in one place.If you entered a token directly in an earlier version, it keeps working. Use Save as workspace secret on the capability card whenever you want to switch: the stored token is copied into a new secret, so you never have to enter it again.Leave GitHub host empty if you use github.com. On GitHub Enterprise, enter your instance’s host name — for example yourcompany.ghe.com or github.yourcompany.com. Enter the host name only, without https:// and without a path.If you want the agent to react to GitHub events (via webhooks), tick Incoming (webhooks) and enter the repositories to watch in the Watched repositories field — for example, owner/repo or myorg/myrepo. Multiple repos can be comma-separated. An agent can have only one of the two cards ticked: outgoing-only agents call GitHub when asked, incoming-only agents just react to pull requests.
3

Set up webhooks (optional)

To trigger your agent when a pull request is opened in GitHub, configure a webhook in each repository you’re watching:
  1. Go to your repository → Settings → Webhooks → Add webhook (on GitHub Enterprise, on your own instance)
  2. Set the Payload URL to:
    Enterprise customers on a dedicated deployment will have a different base URL. Replace service.abundly.ai with your organization’s service host, in the form <your-tenant>.service.abundly.ai.
  3. Set Content type to application/json
  4. In Secret, enter a long random string. Save the same string as a Webhook signing secret in your workspace’s Secrets and select it in the Webhook secret field on the capability (the capability shows the webhook URL next to that field)
  5. Under Which events would you like to trigger this webhook?, choose Let me select individual events and tick only Pull requests
  6. Click Add webhook
Abundly only accepts events that GitHub signed with the secret, so nobody else can send your agent fake pull requests. The capability can’t be saved with watched repositories but no webhook secret. Agents set up before webhook secrets existed keep working with unsigned events until they are saved again.Abundly reacts to newly opened pull requests only. Other events — pushes, issues, comments — are acknowledged and ignored, so subscribing to them only adds traffic. To react to other events, or to handle the payload your own way, give the agent its own webhook endpoint in its Webhooks capability instead — see Webhooks.With the webhook configured, your agent is notified whenever a pull request is opened in the repository. However, you also need to instruct the agent on what to do with it — otherwise it will likely ignore the event. For example, add to your agent’s instructions: “When a pull request is opened, review the changes and leave a summary comment.”
Without webhooks, your agent can still work with GitHub — but only when you ask it to (via chat or scheduled tasks).

​
Connect with a GitHub App

1

Create and install the app

In GitHub, go to your organization’s Settings → Developer settings → GitHub Apps and create an app. Give it the repository permissions your agent needs (for example Contents, Pull requests and Issues), then install it on the repositories the agent should reach.Note the App ID shown at the top of the app’s settings page. Under Private keys, generate a key and download the .pem file.The installation ID is on the account the app is installed on, not on the app itself: for an organization, go to Organization settings → Third-party access → GitHub Apps; for a user account, Settings → Applications → Installed GitHub Apps. Click Configure next to the app — the installation ID is the number at the end of the page’s address, …/settings/installations/12345678.
2

Configure in Abundly

In the GitHub capability, tick Outgoing (API calls), choose GitHub App as the authentication method and add a GitHub App workspace secret with the App ID, installation ID and the contents of the .pem file. Abundly uses the key to request short-lived tokens for the app as the agent needs them; the key itself is never sent to GitHub.Optionally narrow what this agent can do with the app:
  • Limit to repositories — for example api, web. The agent can only reach these, even if the app is installed on more.
  • Limit permissions — for example contents:read, pull_requests:write. This can only narrow the app’s own permissions, never add to them.
Different agents can use the same app with different limits, or different apps.
3

Webhooks (optional)

Instead of adding a webhook to every repository, you can use the app’s own webhook: on the app’s settings page, enable Webhook, set the URL to https://service.abundly.ai/api/github/webhook (on a dedicated deployment, https://<your-tenant>.service.abundly.ai/api/github/webhook; the capability shows the URL next to the Webhook secret field), set a Webhook secret, and subscribe to Pull request events under Permissions & events. Then tick Incoming (webhooks) on the capability, save the same secret as a Webhook signing secret in your workspace’s Secrets, select it in the Webhook secret field, and list the repositories to react to under Watched repositories. As with repository webhooks, the secret is required whenever repositories are watched, and only newly opened pull requests reach the agent — for anything else, use the agent’s own webhook endpoint.
Every GitHub call an agent makes is visible where it was made — in the chat, or in the activity log for triggered runs — including the API path and so the repository it targeted.

​
GitHub Enterprise

Both GitHub Enterprise products are supported. Enter your host name in the GitHub host field and Abundly detects which one you use — there is nothing else to configure. Two things are specific to Enterprise:
  • Create the token or app on your own instance. A github.com token or app does not work against an Enterprise host, and the reverse is also true.
  • Use your instance for repository settings. Watched repositories are still written as owner/repo, but you add webhooks in the repository settings on your own instance.

​
IP allowlisting

If your enterprise restricts access by IP address — GitHub’s own IP allow list setting on Enterprise Cloud, or your firewall in front of a self-hosted instance — allow Abundly’s outbound IP address:
Enterprise customers connect from a different, dedicated IP address. If you’re an enterprise customer and need to allowlist Abundly, contact us and we’ll provide your specific address.
The IP allow list is an Enterprise Cloud feature and doesn’t depend on data residency, so it can apply even when you leave the GitHub host field empty — an organization on Enterprise Cloud without data residency still uses github.com. GitHub.com Free, Pro, and Team accounts have no IP restrictions, so there is nothing to allowlist.

​
Self-hosted reachability

These two requirements apply only to Enterprise Server. An instance that is reachable only inside your network cannot be used, because the connection has to work in both directions:
  • Abundly calls your instance’s API at https://your-host/api/v3, so the host must be reachable from the internet.
  • Your instance calls Abundly at https://service.abundly.ai/api/github/webhook if you use webhooks, so it needs outbound access to that address. On a dedicated deployment, allowlist your own service host instead — https://<your-tenant>.service.abundly.ai/api/github/webhook.
Enterprise Cloud with data residency (*.ghe.com) is hosted by GitHub and reaches Abundly the same way github.com does, so neither reachability requirement applies to it.