GitHub
Your customers connect their GitHub org once and Askel handles everything from there. Pull requests, repo events, issue labels, and Actions run results flow into your product without your team writing a single line of webhook plumbing.
What you can do
React to pull request lifecycle events
Trigger workflows when a PR is opened, marked ready for review, approved, merged, or closed. Filter by base branch, label, or repo so only the right events land in your product.
Read and write issue labels
Pull the current label set from any repo the customer authorized. Add or remove labels programmatically, for example to mark an issue as synced once it has been imported into your product.
Monitor GitHub Actions run results
Subscribe to workflow run completions and surface pass or fail status in your product alongside the commit SHA and branch that triggered the run.
Scope access to exactly the repos the customer chooses
The GitHub App installation lets admins pick specific repos rather than the whole org. Askel enforces that boundary and will not request data from repos outside the selection.
Create and update issues from your product
Open new issues, append comments, and update assignees or milestones in the customer's repo. Useful for writing back test failures, deployment notes, or support tickets.
Fetch commit and branch metadata
Read branch names, latest commit SHAs, and commit messages for the repos in scope. Lets your product link its own records to the exact commit that produced them.
Surfacing deployment-blocking PRs inside a release-tracking product
You sell release-management software. A customer, Crestline Software, manages three production services in a monorepo called crestline/platform. Their release process requires that every PR targeting the release/v4.2 branch passes two required status checks and carries the label approved-for-release before a release can be cut. Today that check is manual.
- 1
Connect GitHub
Crestline's GitHub org admin clicks Connect GitHub inside your product. Askel redirects to GitHub's App installation flow, the admin selects the crestline/platform repo, and approves read access to pull requests, issues, and statuses.
- 2
Configure the watch rule
In your product's onboarding wizard, a Crestline admin sets the target repo to crestline/platform, the base branch filter to release/v4.2, and the required label to approved-for-release. Askel registers the webhook on their behalf.
- 3
Events start flowing
Each time a PR targeting release/v4.2 is opened, updated, or labeled, Askel forwards the structured event to your product's ingest endpoint with the PR title, author, current label list, and status check roll-up.
- 4
Your product builds the blocking list
Your product queries the current open PRs for release/v4.2, identifies the three PRs that are missing the approved-for-release label or have a failing ci/build check, and surfaces them in the release dashboard with direct links.
- 5
Release gate clears automatically
Once the last blocking PR is merged, Askel sends the pull_request.closed event, your product marks the release/v4.2 gate as green, and the release lead gets a notification that the cut can proceed.
OAuth 2.0
The customer's GitHub org admin (or a repo maintainer with org-install rights) clicks Connect inside your product. Askel opens the GitHub App installation flow, the admin selects which org or repos to grant access to, and approves the requested scopes. Askel stores the installation token and rotates it automatically; your product never sees a raw credential.
How Askel sits between your product and the customer's system
FAQ for GitHub
Does the customer need to be an org admin to connect?+
What happens if the customer revokes the GitHub App installation?+
Can a customer connect multiple GitHub orgs?+
Is there a limit on the number of repos that can be included in a single connection?+
catching drift before it breaks, and hitting go-live dates.
© 2025 Askel.ai. All rights reserved.