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 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:

{
  "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:

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

Monitor pull request and issue activity:

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

Track releases and deployments:

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

Listen for every repository event:

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

Track security-related repository events:

{
  "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.