GitHub Email to Webhook Integration

Why Connect GitHub to Inbound Email

GitHub powers production systems that need to react to external events. Email is still a common delivery mechanism for alerts, notifications, and inter-service messages — especially from legacy systems or third-party services that don't offer webhooks. JsonHook gives your GitHub integration a reliable inbound email endpoint that delivers clean, structured JSON.

Connecting your inbound email to GitHub through JsonHook unlocks a range of high-value automation scenarios:

• Receive webhook-style callbacks from services that only support email notifications
• Forward CI/CD alert emails into your incident management pipeline
• Parse structured data out of report emails and insert it into your database
• Trigger serverless functions whenever a specific email pattern is matched
• Bridge legacy systems that communicate via email to modern webhook-driven APIs

GitHub supports GitHub REST API (Issues, Discussions, Repositories endpoints), which makes it a natural target for JsonHook's outbound POST requests. Every email that hits your JsonHook address is parsed within milliseconds and delivered to GitHub as a clean JSON object — no polling, no manual export, no middleware server to maintain.

Setting Up GitHub with JsonHook

The following steps walk you through connecting JsonHook to GitHub. The entire setup typically takes under ten minutes.

1. Step 1: Generate a GitHub Personal Access Token (PAT) with repo scope from Settings → Developer settings → Personal access tokens.
2. Step 2: Create a small HTTP handler or use n8n/Make to receive the JsonHook webhook POST. The handler calls the GitHub API to create an issue, post a comment, or trigger a workflow dispatch.
3. Step 3: In JsonHook, create an inbound address (e.g., [email protected]) and set the destination to your HTTP handler or automation webhook URL.
4. Step 4: Map subject to the GitHub Issue title and text to the Issue body. Include from.address in the issue body as the reporter reference.

Once the connection is active, every email sent to your JsonHook address will be automatically parsed and forwarded to GitHub. You can test the integration by sending a plain-text email to your JsonHook address and verifying that the payload appears in GitHub within a few seconds.

JsonHook supports GitHub REST API (Issues, Discussions, Repositories endpoints) on the GitHub side, so no additional configuration is needed in GitHub beyond the steps above. If GitHub requires header-based authentication for incoming webhooks, add the required headers in the JsonHook endpoint configuration under Advanced Settings.

Example Workflow: When a bug report email arrives, automatically create a GitHub Issue in the relevant repository

This walkthrough demonstrates one concrete way to use JsonHook with GitHub. The scenario: When a bug report email arrives, automatically create a GitHub Issue in the relevant repository.

When an email matching this scenario arrives, JsonHook parses the raw SMTP message and constructs the following JSON payload before POSTing it to your GitHub endpoint:

{
  "messageId": "",
  "from": {
    "name": "Jane Smith",
    "address": "[email protected]"
  },
  "to": [
    { "address": "[email protected]" }
  ],
  "subject": "When a bug report email arrives, automatically create a GitHub Issue in the relevant repository",
  "text": "Hi, I need help with my account. Please contact me at your earliest convenience.",
  "html": "
Hi, I need help with my account...
",
  "date": "2026-03-15T10:32:00.000Z",
  "attachments": [],
  "headers": {
    "x-priority": "1"
  }
}

GitHub Issue creation endpoint POST /repos/{owner}/{repo}/issues: subject → title, text → body, parse labels from subject keywords → labels[]. Optionally set assignees[] based on a routing table keyed on the email recipient address.

Once GitHub receives this payload, it can execute any downstream action — whether that is posting a notification, creating a record, updating a field, or triggering an entire multi-step workflow. The key advantage is that the data arrives as structured JSON, so GitHub never needs to parse raw email text or deal with MIME encoding.

Payload Mapping for GitHub

JsonHook delivers a consistent JSON schema for every parsed email. The table below shows which JsonHook fields map to the equivalent fields in GitHub. Use this as a reference when configuring your GitHub GitHub REST API (Issues, Discussions, Repositories endpoints).

Not every field will be present in every email. Always check for null or missing values before mapping to required fields in GitHub. For text-only emails, html will be empty; for HTML-only emails, text may be empty or auto-generated from the HTML. The attachments array will be an empty array when no files are attached.

Best Practices for GitHub Email Integration

Following these best practices will make your GitHub email integration more reliable, easier to debug, and simpler to scale as your email volume grows.

• Use dedicated addresses per workflow. Create a separate JsonHook inbound address for each distinct GitHub workflow you want to trigger. This makes routing explicit and avoids a single endpoint becoming a bottleneck for all email types.
• Validate the payload before acting. In GitHub, add a conditional check at the start of your workflow to confirm that required fields like from.address and subject are present and non-empty before executing downstream actions.
• Test with real emails first. Use JsonHook's delivery log to inspect the raw JSON payload before wiring up GitHub. Confirm that all the fields you plan to map are actually populated by your email source.
• Handle errors gracefully. Configure GitHub to catch webhook delivery failures and send an alert. JsonHook will retry failed deliveries, but your GitHub endpoint should return a 2xx status promptly to acknowledge receipt.
• Keep secrets out of email content. Avoid routing emails that contain passwords, API keys, or PII through workflows unless you have appropriate data-handling controls configured in GitHub. Use JsonHook's HTTPS delivery to protect data in transit.