How to Process Incoming GitHub Webhooks

Trigger workflows from GitHub events like pushes, pull requests, and issues using the GitHub Webhook trigger.

What This Integration Does

GitHub emits webhooks for almost every event that happens in a repository - pushes, pull requests opened or merged, issues created or commented, releases published, deployments. Spojit's Webhook trigger receives these events and routes them through a workflow that can post Slack updates, sync into project trackers, fan out CI/CD notifications, or kick off review automation. Anything you'd otherwise glue together with a small server and a cron job is a one-workflow job here.

The trigger validates GitHub's X-Hub-Signature-256 header automatically using the signing secret stored on the Connection, so unauthenticated requests never reach your workflow. Inside the workflow, you read the event type from the X-GitHub-Event header and the action (opened, closed, merged, etc.) from the body, then branch with Condition nodes to handle each case.

Prerequisites

Admin (or maintainer) access to the GitHub repository where you want to add the webhook.
A Webhook trigger connection in Spojit, which generates the URL and signing secret you'll paste into GitHub.
Connections for whatever downstream systems you're routing to - typically slack, monday, or a custom REST endpoint via http.

Step 1: Create the Webhook Trigger in Spojit

Create a new workflow, drop a Trigger node, and set its type to Webhook. Save the workflow and copy the generated webhook URL and signing secret from the trigger config. Keep the workflow open in a tab - you'll be coming back to it.

Step 2: Register the Webhook in GitHub

In your GitHub repository go to Settings → Webhooks → Add webhook. Paste the Spojit webhook URL into Payload URL, set Content type to application/json, paste the signing secret into Secret, and choose which events to send. Send me everything works for prototyping; for production pick only the events you actually handle (typically pushes, pull requests, issues, releases). Save the webhook - GitHub will fire a ping event immediately so you can confirm Spojit received it.

Step 3: Route by Event Type

Back in the workflow, add a Condition node right after the trigger to branch on {{ trigger.headers["x-github-event"] }}. A 3- or 4-way branch covers most uses: push, pull_request, issues, release. The default branch can just end the workflow - GitHub sends many event types you won't care about.

Step 4: Push Branch - Post Commit Summary to Slack

On the push branch, add a Transform node that pulls the commit list out of {{ trigger.body.commits }}, formats each as a short bullet with author and message, and joins them. Then add a Connector node calling slack send-message with the formatted text. Include the repository name, branch, and a link to the compare URL ({{ trigger.body.compare }}) so engineers can click straight through.

Step 5: Pull Request Branch - Create or Update a Tracking Item

On the pull_request branch, use a nested Condition on {{ trigger.body.action }} to distinguish opened from closed and merged. For opened PRs, call monday create-item on a code-review board with title, author, and link. For merged PRs, use monday update-item to flip the status to Merged. For all PR events, post a brief notification via slack send-message to the review channel. Optionally pipe the PR body through an AI step to generate a one-line summary for the Slack post.

Step 6: Issues and Releases Branches

On the issues branch, route by action - opened issues notify support via front send-message or slack send-message; closed issues are usually ignorable. On the release branch, post the release notes to slack and trigger any downstream deploy workflows via a Subworkflow node. Wrap each external call with the standard retry settings so transient outages in Slack or Monday don't lose the event.

Tips

The body field action is your friend - opened, closed, merged, labeled, commented all flow through the same event type and need fine-grained Condition routing.
Add an AI summarisation step for big PRs and release notes - the raw text is often noisy.
Use regex extract on commit messages to pull out ticket IDs (e.g. JIRA-1234) and link the PR to your project tracker automatically.
GitHub retries failed webhook deliveries with backoff for 8 hours - if your workflow is briefly down, events aren't lost as long as you eventually return 2xx.

Common Pitfalls

Signature mismatch - if you paste the secret wrong, Spojit rejects every event with a 401 and your workflow never runs. Test with the GitHub ping event right after setup.
Treating pull_request as one thing - opened, synchronized, closed, and merged all arrive as the same event type. Always check body.action.
Bot loops - if your workflow comments back on the PR, that comment can re-fire the webhook. Filter out events where body.sender.type === "Bot" at the top.
Large payloads - monorepo pushes can contain thousands of commits. Truncate the commit list before formatting or your Slack post will exceed Slack's message size limit.

Testing

Use GitHub's Recent Deliveries tab on the webhook config to replay a ping (or a real event) without making a new commit. Inspect the Spojit execution log to confirm the signature passed, the event type branched correctly, and the downstream notifications fired. Then make a small test commit on a branch nobody watches and trace it end-to-end before turning broader event types on.