<!-- BusyBot node reference — https://busybot.net/tools/github-trigger/ -->

> Node: GitHub Trigger (`github_trigger`) · Webhook trigger · v1
> Category: Development · Credentials: GitHub API (`githubApi`)
> Updated: 2026-08-16

# GitHub Trigger

> Trigger workflows on GitHub repository events

## Overview

The GitHub Trigger node starts a workflow when events occur in a GitHub repository. It creates a webhook on the specified repository and listens for selected events such as push, pull_request, issues, releases, deployments, and 40+ other GitHub event types. Supports HMAC-SHA256 signature verification for secure webhook delivery. Outputs the full event payload including body, headers, and query parameters.

**Category:** Development  
**Tool Name:** `github_trigger`  
**Version:** 1

**Appearance:** Icon: `si-github` | Color: `#24292e`

## Node Type

**Trigger** — webhook (receives incoming HTTP callbacks)

## Input / Output

| Direction | Port(s) |
|-----------|--------|
| Input | None (trigger node) |
| Output | `Output` |

## Credentials

This tool requires **GitHub API** credentials.
See the [Credentials Guide](https://busybot.net/credentials/github-api/) for setup instructions.

### Parameters

| Parameter | Type | Required | Default | Description |
|-----------|------|----------|---------|-------------|
| Repository Owner | `string` | Yes | — | The owner (user or organization) of the GitHub repository. |
| Repository Name | `string` | Yes | — | The name of the GitHub repository to watch for events. |
| Events | `multiOptions` | Yes | `[]` | The events to listen for. Select one or more. |
| | | | | Options: `*` (Wildcard — any time any event is triggered), `check_run`, `check_suite`, `commit_comment`, `create` (a repository, branch or tag was created), `delete` (a branch or tag was deleted), `deploy_key`, `deployment`, `deployment_status`, `fork`, `github_app_authorization`, `gollum` (a wiki page was created or updated), `installation`, `installation_repositories`, `issue_comment`, `issues`, `label`, `marketplace_purchase`, `member`, `membership` (organization hooks only), `meta` (this webhook itself was deleted), `milestone`, `org_block` (organization hooks only), `organization` (organization hooks only), `page_build` (a push to a GitHub Pages enabled branch), `project`, `project_card`, `project_column`, `public` (a private repository was open sourced), `pull_request`, `pull_request_review`, `pull_request_review_comment`, `push`, `release`, `repository`, `repository_import`, `repository_vulnerability_alert`, `security_advisory`, `star` (a star was added or removed), `status` (the status of a Git commit changed), `team` (organization hooks only), `team_add`, `watch` (someone starred the repository) |
| Options | `collection` | No | `{}` | Additional options for the GitHub webhook. |
| — Insecure SSL | `boolean` | No | `false` | Whether the SSL certificate of the webhook host should be verified by GitHub when delivering payloads. |

## Output Data

Each accepted delivery produces one output item describing the GitHub event:

```json
{
  "body": {},
  "headers": {},
  "query": {},
  "_trigger": "github_webhook",
  "_timestamp": "2026-01-01T00:00:00.000Z",
  "_webhookEvent": "push",
  "_deliveryId": ""
}
```

- `body` — the GitHub event payload exactly as GitHub sent it (for example `action`, `repository`, `sender`, and the event-specific fields).
- `headers` — the request headers of the delivery.
- `query` — the query-string parameters of the delivery.
- `_trigger` — always `github_webhook`.
- `_timestamp` — ISO 8601 timestamp of when the delivery arrived.
- `_webhookEvent` — the GitHub event name taken from the `X-GitHub-Event` header, or `unknown` when the header is absent.
- `_deliveryId` — the value of the `X-GitHub-Delivery` header, useful for de-duplication.

Reference the payload downstream by expression, for example `{{ $json.body.repository.full_name }}` or `{{ $json._webhookEvent }}`.

The ping GitHub sends immediately after the webhook is created is acknowledged but does not start the workflow, and deliveries whose signature does not match are rejected with `401`.

## Usage Examples

- Start a workflow when code is pushed to a repository
- Trigger a deployment pipeline when a pull request is merged
- Notify a team channel when a new issue is opened
- Run tests when a pull request review is submitted
- Track repository stars and forks in a dashboard

## Example Configuration

Monitor a repository for push events only:

```json
{
  "type": "github_trigger",
  "parameters": {
    "owner": "mycompany",
    "repository": "my-app",
    "events": ["push"]
  }
}
```

Monitor pull request and issue activity:

```json
{
  "type": "github_trigger",
  "parameters": {
    "owner": "myorganization",
    "repository": "project-repo",
    "events": ["pull_request", "issues", "issue_comment"],
    "options": {
      "insecureSSL": false
    }
  }
}
```

Track releases and deployments:

```json
{
  "type": "github_trigger",
  "parameters": {
    "owner": "acme-corp",
    "repository": "production-app",
    "events": ["release", "deployment", "deployment_status"]
  }
}
```

Listen for every repository event:

```json
{
  "type": "github_trigger",
  "parameters": {
    "owner": "myuser",
    "repository": "test-repo",
    "events": ["*"]
  }
}
```

Track security-related repository events:

```json
{
  "type": "github_trigger",
  "parameters": {
    "owner": "security-org",
    "repository": "secure-app",
    "events": ["repository_vulnerability_alert", "security_advisory", "member"],
    "options": {
      "insecureSSL": false
    }
  }
}
```

### Trigger Behavior

- **Activation:** When the workflow is activated, a webhook endpoint is registered with the service.
- **Deactivation:** The webhook is automatically unregistered when the workflow is deactivated.
- **Payload:** The incoming webhook payload is parsed and output as workflow items.
- **Verification:** Supports signature verification where applicable.

## Tips

The GitHub Trigger listens for events from a GitHub repository. Configure the repository owner, repository name, and which events to listen for. When a matching event occurs, the workflow starts with the full event payload. Optionally provide a webhook secret for HMAC-SHA256 signature verification.

Only members with owner privileges for an organization or admin privileges for a repository can set up the webhooks this node requires.