GitHub

Supported Event Types

How to Configure the GitHub Webhook

After saving your GitHub node in BizFirst, point GitHub to the BizFirst endpoint for each event type you want to handle:

1. In your GitHub repository (or organisation), go to Settings > Webhooks > Add webhook.
2. Set Payload URL to the BizFirst endpoint for the event type — for example https://app.bizfirstai.com/webhooks/github/push.
3. Set Content type to application/json.
4. If using WebhookSecret, paste the same secret value in both GitHub and the BizFirst node settings.
5. Select the specific events to send (push, pull_request, issues, etc.) or choose "Send me everything".
6. Save the webhook. GitHub will send a ping event — the node will receive it but will not start a workflow run.

Filtering Events

The node settings let you filter which events actually trigger a workflow run. Filters include allowed repositories, organisations, branches, PR actions, and issue actions. Events that do not pass the configured filters are silently discarded — the workflow is never started.

• Filter by specific repositories using owner/repo format
• Filter push events to specific branches — wildcards supported (e.g. release/*)
• Filter pull request events by action (opened, synchronize, closed, etc.)
• Filter issue events by action (opened, closed, labeled, etc.)
• Restrict to organisation members or users with push access
• Skip empty push events with OnlyProcessNonEmptyPushes
• Deduplicate retried deliveries with EnableIdempotencyCheck

Output Data

Each event type produces structured output fields that downstream nodes can reference. All events include common fields (repository name, owner, sender, timestamp) plus event-specific fields:

• push: branch, commits array, forced_push, pusher
• pull_request: PR number, title, state, head/base branch, labels, reviewers
• issues: issue number, title, state, labels, assignees
• release: release name, tag, prerelease flag, asset count
• workflow_run: run ID, workflow name, status, conclusion, branch

Use Cases

Auto-Deploy on Push to Main

When a push event arrives for the main branch of your production repository, trigger a deployment pipeline — run tests, update staging, notify the team in Slack, and promote to production after approval.

PR Review Bot

When a pull request is opened, run automated checks — post a comment with the diff summary, assign reviewers based on file ownership rules, and label the PR with the affected service area.

Auto-Close Stale Issues

When an issue is labelled "stale" by a triage workflow, trigger a BizFirst workflow that adds a closing comment, closes the issue after 7 days of no activity, and logs the closure in your project management tool.

Release Notes Generation

When a release is published, collect all merged PRs since the previous tag, generate formatted release notes, post them to Confluence, and notify the product team in Slack.

CI Failure Alert

When a workflow_run event arrives with conclusion failure, page the on-call engineer, create a GitHub issue, and post the failure details to the engineering channel.

In This Guide