GitHub Webhook Trigger github-webhook

When to Use

• CI/CD automation: Trigger a build, test, or deployment workflow the moment a commit lands on a protected branch, keeping infrastructure changes tightly coupled to code changes with no polling overhead.
• PR review notifications: Fire a notification workflow when a pull request is opened, synchronised, or marked ready for review, routing it to the right reviewer team automatically.
• Issue tracking sync: Create or update records in an internal project tracker whenever a GitHub issue is opened, labelled, or closed, keeping both systems consistent without a manual import step.
• Release deployment triggers: Automatically kick off a deployment pipeline when a non-prerelease tag is published on GitHub, replacing manual approval steps with a verified, auditable trigger.
• Code change notifications: Alert on-call teams or compliance systems when commits land on main from external contributors, using allowedRepositories and requireOwnerOrMember to scope the alert precisely.

Configuration

Security

Event Filtering

Access Control

Sample Configuration JSON

{
  "webhookSecret": "{{ $credentials.github-webhook-secret }}",
  "allowedEventTypes": "push,pull_request",
  "allowedRepositories": "myorg/api,myorg/worker",
  "allowedBranches": "main,release/*",
  "allowedPullRequestActions": "opened,synchronize,closed",
  "enableIdempotencyCheck": true,
  "onlyProcessNonEmptyPushes": true,
  "requireOwnerOrMember": true
}

Validation Errors

Output

Success Port — Common Fields

Present on every successful execution regardless of event type:

Event-Specific Fields

Error Port

Fires when signature verification fails, the event type is not in allowedEventTypes, the sender fails an access control check, or the webhook body cannot be parsed. The output object contains errorCode and message string fields.

Sample Output JSON — Push Event

{
  "event_type": "push",
  "repository": "myorg/api",
  "repository_id": 123456,
  "repository_url": "https://github.com/myorg/api",
  "repository_private": true,
  "branch": "main",
  "before_commit": "abc1234567890def1234567890abcdef12345678",
  "after_commit": "def5678901234abc5678901234def567890abcde",
  "action": "pushed",
  "sender_login": "developer1",
  "sender_type": "User",
  "owner_login": "myorg",
  "owner_type": "Organization",
  "timestamp": "2026-05-26T09:15:30Z",
  "commits": [
    {
      "id": "def5678901234abc5678901234def567890abcde",
      "message": "fix: correct payment rounding on invoice totals",
      "author": "Jane Smith",
      "author_email": "jane@myorg.com",
      "url": "https://github.com/myorg/api/commit/def5678901234abc",
      "timestamp": "2026-05-26T09:14:55Z",
      "has_changes": true
    }
  ],
  "_webhook_method": "POST",
  "_webhook_path": "/webhooks/github/push",
  "_webhook_received_at": "2026-05-26T09:15:31.042Z"
}

Expression Reference

Node Policies & GuardRails

• Never skip signature verification. Always provide a webhookSecret. The node uses constant-time comparison of the HMAC-SHA256 over the raw body against the X-Hub-Signature-256 header. Do not configure a blank or wildcard secret.
• Store secrets in Credentials Manager. Reference stored credentials with {{ $credentials.name }}. Never paste raw webhook secret values into the node configuration field or commit them to source control.
• Enable idempotency for downstream writes. GitHub retries deliveries on network timeout. Set enableIdempotencyCheck: true and include idempotency handling in any downstream node that writes to a database or external system.
• Scope allowedRepositories in multi-tenant environments. If multiple workflows share one BizFirstAI tenant, use allowedRepositories to ensure each workflow fires only for the intended repository.
• Filter at the trigger — not inside the workflow. Use allowedBranches, allowedPullRequestActions, and allowedIssueActions rather than adding an If-Condition node as the first step; filtering at the trigger avoids unnecessary workflow runs and reduces execution cost.
• Apply access control flags for public repositories. For open-source repositories, set requireOwnerOrMember: true or requireContributorAccess: true to prevent external fork events from triggering internal automation.

Examples

Push to Main — Trigger Deployment Pipeline

{
  "webhookSecret": "{{ $credentials.github-deploy-secret }}",
  "allowedEventTypes": "push",
  "allowedRepositories": "myorg/api",
  "allowedBranches": "main",
  "onlyProcessNonEmptyPushes": true,
  "enableIdempotencyCheck": true
}

Only push events to the main branch of myorg/api start the deployment workflow. Empty pushes (branch creation, tag operations with no commits) are discarded. The X-GitHub-Delivery header prevents a GitHub retry from launching a duplicate deployment.

Pull Request Opened or Updated — Notify Review Team

{
  "webhookSecret": "{{ $credentials.github-pr-secret }}",
  "allowedEventTypes": "pull_request",
  "allowedRepositories": "myorg/api",
  "allowedPullRequestActions": "opened,synchronize,review_requested",
  "requireOwnerOrMember": true
}

Fires a Slack or email notification to the assigned reviewers when a team member opens a PR, pushes new commits to an open PR, or explicitly requests a review. External fork pull requests from contributors outside the organization are blocked by requireOwnerOrMember.

Issue Opened or Labelled — Create Jira Ticket

{
  "webhookSecret": "{{ $credentials.github-issue-secret }}",
  "allowedEventTypes": "issues",
  "allowedRepositories": "myorg/api,myorg/worker",
  "allowedIssueActions": "opened,labeled",
  "allowedOrganizations": "myorg"
}

When an issue is opened or a label is applied across either monitored repository, the downstream Jira node creates a ticket pre-populated with the issue title, body, and labels. The allowedOrganizations filter ensures events from forks under other organizations are dropped before execution.