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. In Spojit, anything you would otherwise glue together with a small server and a cron job becomes a single workflow.

The Webhook trigger verifies each request with HMAC using a GitHub signing connection, so unauthenticated requests never reach your workflow. The trigger output is the parsed JSON body of the event, available as {{ input }}. GitHub payloads carry an action field plus event-specific objects (pull_request, issue, release, or a commits array for pushes), so you read those from {{ input }} and branch with Condition nodes to handle each case. The trigger returns 202 with an executionId as soon as it accepts the event.

Prerequisites

Admin (or maintainer) access to the GitHub repository where you want to add the webhook.
A GitHub signing connection in Spojit, which the Webhook trigger uses to verify each delivery. The trigger gives you the URL and signing secret to paste into GitHub.
Connections for whatever downstream systems you are routing to: typically slack, monday, or a custom REST endpoint via the http connector.

Step 1: Create the Webhook Trigger in Spojit

Create a new workflow, drop a Trigger node, and set its type to Webhook. For the signing scheme, choose GitHub so the trigger validates each delivery against the secret you share with GitHub. Save the workflow and copy the generated webhook URL and signing secret from the trigger config. Keep the workflow open in a tab: you will 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 fires 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. GitHub payloads identify the event by which object they carry, so branch on the presence of those fields in {{ input }}: a commits array means a push, a pull_request object means a PR event, an issue object means an issue event, and a release object means a release. Chain a few Condition nodes (or use one Condition per event you handle) to cover push, pull request, issues, and release. Anything that does not match can simply end the workflow, since GitHub sends many event types you will not 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 {{ input.commits }}, formats each as a short bullet with author and message, and joins them. Then add a Connector node in Direct mode calling slack send-message with the formatted text. Include the repository name, branch, and a link to the compare URL ({{ input.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 {{ input.action }} to distinguish opened from closed and merged. For opened PRs, use a Connector node in Direct mode calling 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. To generate a one-line summary of the PR for the Slack post, add a Connector node in Agent mode with a prompt that summarizes {{ input.pull_request.body }}.

Step 6: Issues and Releases Branches

On the issues branch, route by {{ input.action }}: opened issues notify support via front send-message or slack send-message, while closed issues are usually ignorable. On the release branch, post the release notes to slack with send-message and trigger any downstream deploy workflows via a Subworkflow node, which runs another workflow as a step and returns its result. Branch each event toward only the connectors it needs so a slow response in Slack or Monday does not hold up the others.

Tips

The body field action is your friend: opened, closed, merged, labeled, and commented all arrive for the same kind of event and need fine-grained Condition routing.
For big PRs and release notes the raw text is often noisy, so add a Connector node in Agent mode to summarize it before posting. You can also ask Miraxa, the intelligent layer across your automation, to scaffold that step for you.
Use the regex connector's extract tool 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, so if your workflow is briefly down, events are not lost as long as the trigger eventually accepts them.

Common Pitfalls

Signature mismatch: if you paste the secret wrong, the Webhook trigger rejects every event before the workflow runs, so nothing executes. Test with the GitHub ping event right after setup.
Treating pull_request as one thing: opened, synchronized, closed, and merged all arrive as pull request events. Always check {{ input.action }}.
Bot loops: if your workflow comments back on the PR, that comment can re-fire the webhook. Add a Condition at the top that drops events where {{ input.sender.type }} equals Bot.
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.