When a prospect or customer opens a GitHub issue, that's often the single clearest signal of technical intent you'll get, more concrete than an email reply, more specific than a form fill. Softmatica's GitHub integration links issues, pull requests, and repo activity directly to the deal or account they belong to, so that signal shows up where your reps are already looking instead of getting buried in a separate tool nobody on the sales team opens.

What gets linked, and how

The integration works at two levels. At the account level, connecting a customer's GitHub organization (or a specific repo, for smaller teams) gives you a rolling feed of commits, PR merges, and issue activity tied to that account, useful for spotting integration depth and technical engagement over time. At the deal level, individual issues can be linked explicitly, either automatically by matching on repo and account, or manually when a rep or engineer wants to pin a specific issue to a specific opportunity.

Most teams set this up one of two ways: a webhook from GitHub that pushes issue and PR events to Softmatica in real time, or a scheduled sync that pulls activity every few minutes for organizations that don't want to configure webhooks. The webhook path is faster and is what we recommend for any account generating meaningful GitHub traffic.

API · manually link a GitHub issue to a deal
$ curl -X POST https://api.softmatica.net/v1/deals/dl_8f2a/links \
$ -H "Authorization: Bearer $SM_API_KEY" \
$ -H "Content-Type: application/json" \
$ -d '{"type": "github_issue", "ref": "cursive-data/platform#482"}'
{"deal_id": "dl_8f2a", "linked_issue": "#482", "status": "synced", "linked_at": "2026-08-27T14:02:11Z"}

For webhook-driven sync, point your GitHub organization's webhook at Softmatica's ingest endpoint and select the issues, pull_request, and push event types. Softmatica matches incoming events to accounts using the linked repo and, where available, the GitHub org, then updates the relevant deal or account timeline automatically.

Webhook · GitHub issue opened event
$ POST /webhooks/github (configured in GitHub org settings)
{"event": "issues", "action": "opened", "repo": "cursive-data/platform", "issue": "#482", "title": "SSO login fails on SAML redirect"}
→ matched to account "Cursive Data" via linked repo
→ deal "Cursive Data, Growth plan renewal" timeline updated

What this looks like day to day

Cursive Data · deal timeline
GitHub activity3 open issues, 1 PR merged
Linked issue#482 SSO login fails on SAML redirect
Last synced2 minutes ago

A rep opening this deal sees the open issue count and the specific issue title without asking an engineer for a status update. If issue #482 is a blocker for a renewal, that's visible on the deal card itself, not three Slack messages away.

Using linked issues in automation

Once issues are linked, you can build automation rules on top of them. Common patterns teams set up:

  • Alert the account owner in Slack when a high-priority issue is opened on a linked repo for any account in "negotiation" or later stage.
  • Automatically flag a renewal deal as at-risk when open issue count on the linked account crosses a threshold (say, more than 5 open issues older than 14 days).
  • Trigger a CS check-in task when a previously open issue is closed, since issue resolution is often a good moment to re-engage a stalled expansion conversation.

Setup checklist

  • Connect your GitHub organization under Settings → Integrations → GitHub, authorizing read access to the repos you want synced.
  • Map repos to accounts, either automatically (Softmatica suggests matches based on org name and existing account domains) or manually for edge cases.
  • Configure the webhook (recommended) or enable scheduled sync (every 5 minutes by default, configurable down to every minute on Growth plan and above).
  • Decide which event types matter to your team. Most teams start with issues and pull_request and add push later if commit-level detail is useful.

This same linking pattern extends to Linear and Jira for teams that manage customer-facing work there instead of, or alongside, GitHub issues. The setup steps are nearly identical: connect the workspace, map projects to accounts, choose real-time or scheduled sync.