> For the complete documentation index, see [llms.txt](https://docs.appmixer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmixer.com/connector-configuration/github.md).

# GitHub

## Register OAuth app

Go to **GitHub → Settings → Developer settings → OAuth Apps → New OAuth App** (for an organization-owned app: **Organization settings → Developer settings → OAuth Apps**).

* **Application name** and **Homepage URL**: anything your users should recognise.
* **Authorization callback URL**: `https://<your-appmixer-api>/auth/github/callback` — replace the host with your Appmixer API URL and keep the suffix `/auth/github/callback`.

Generate a client secret and create the `appmixer:github` configuration in the [Backoffice](https://docs.appmixer.com/getting-started/services) with `clientId` and `clientSecret`.

{% hint style="info" %}
If the GitHub organization your users work with restricts third-party OAuth app access (**Organization settings → Third-party access → OAuth app policy**), an organization owner has to approve the Appmixer app there. Until then the connector reads public data but every write into the organization's repositories fails with `403 — OAuth App access restrictions`.
{% endhint %}

## Organization webhook for the project board trigger

The **On Project Item Changed** trigger (`projects_v2_item` events — a card on a Projects (v2) board changes its Status or another field) does not register anything on GitHub itself. GitHub delivers these events only through an **organization webhook**, and only an organization owner can manage those, so the webhook is created once per organization by an owner and every flow with the trigger subscribes to it through the connector.

### 1. Give the connector a webhook secret

Add a `webhookSecret` key to the `appmixer:github` configuration in the [Backoffice](https://docs.appmixer.com/getting-started/services), or with the CLI:

```bash
appmixer service-config set appmixer:github -u -d '{"webhookSecret": "<secret>"}'
```

Any long random string works — for example the output of `openssl rand -hex 32`. GitHub signs every delivery with it (`X-Hub-Signature-256`) and the connector drops deliveries whose signature does not match.

### 2. Create the organization webhook

As an owner of the organization, open **Organization settings → Webhooks → Add webhook** and fill in:

* **Payload URL**: `https://<your-appmixer-api>/plugins/appmixer/github/events`
* **Content type**: `application/json`
* **Secret**: the same value as `webhookSecret`
* **SSL verification**: enabled
* **Which events would you like to trigger this webhook?**: *Let me select individual events* → tick only **Project v2 items**

![Adding the organization webhook](https://802996127-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIAGKHlIqVKJe9agnFr14%2Fuploads%2Fgit-blob-ce04563f088842206ac9629dbd859881505fbe26%2Fgithub-org-webhook.png?alt=media)

The screenshot shows `https://acme.appmixer.ai/…` as an example: put your own Appmixer API URL in front of `/plugins/appmixer/github/events` (the same host your Appmixer API answers on, for example `https://api.acme.appmixer.cloud/plugins/appmixer/github/events`).

Save it. GitHub immediately sends a `ping`, which the connector answers with `200`; you can see it under **Recent Deliveries** of the webhook. One webhook serves every flow on the Appmixer instance.

{% hint style="warning" %}
**Appmixer connected to an Auth Hub.** When your Appmixer instance authenticates GitHub through an Auth Hub, the trigger's subscription lives on the hub, so the **Payload URL must be the hub's endpoint**: `https://<your-auth-hub>/plugins/appmixer/github/events`. The GitHub connector must be installed on the hub and the `webhookSecret` set in the hub's `appmixer:github` configuration. The hub relays every delivery to the subscribed flows of the connected instances.
{% endhint %}

### 3. Use the trigger

In the flow, set the trigger's **Organization** (the login of the organization) and optionally **Project Node ID** (the GraphQL node id of one board, `PVT_…`; leave it empty to receive events of every board of the organization). The account bound to the trigger needs only the `read:org` and `read:project` scopes — they serve Flow Test Mode, which reads the newest card of the board.

If a flow receives nothing, check the webhook's **Recent Deliveries**: a `401` response means the secret in GitHub differs from the connector's `webhookSecret`; a `404` means the URL points at an instance (or a hub) where the connector is not installed.

## Backoffice configuration

Configuration ID: `appmixer:github` (Backoffice → Configuration; see [Connector Configuration](https://docs.appmixer.com/getting-started/services) for how a configuration is created and how its keys reach the connector).

* `clientId` — Client ID of the GitHub OAuth app registered above. Not needed when GitHub is authenticated through the Appmixer Auth Hub.
* `clientSecret` — Client secret of the same OAuth app. Not needed with the Auth Hub.
* `webhookSecret` — The secret of the organization webhook that feeds **On Project Item Changed** (any long random string, the same value as in GitHub). Only needed when that trigger is used. On an Auth Hub setup it belongs to the hub's `appmixer:github` configuration, not to the instance.

The same keys can be set with the CLI (`-u` updates the existing configuration instead of creating it):

```bash
appmixer service-config set appmixer:github -u -d '{
  "clientId": "<client id>",
  "clientSecret": "<client secret>",
  "webhookSecret": "<webhook secret>"
}'
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.appmixer.com/connector-configuration/github.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.