feat(github-enterprise): support GitHub Enterprise Cloud (GHE.com) webhooks and API#113966
Merged
tnt-sentry merged 4 commits intomasterfrom Apr 27, 2026
Merged
feat(github-enterprise): support GitHub Enterprise Cloud (GHE.com) webhooks and API#113966tnt-sentry merged 4 commits intomasterfrom
tnt-sentry merged 4 commits intomasterfrom
Conversation
…prise host header to include GitHub Enterprise Cloud
0b2132d to
5b09d7d
Compare
billyvg
approved these changes
Apr 24, 2026
3 tasks
cleptric
pushed a commit
that referenced
this pull request
May 5, 2026
…bhooks and API (#113966) GitHub Enterprise Cloud with data residency (GHE.com, e.g. \`acme-corp.ghe.com\`) uses a different webhook header and API URL pattern than GitHub Enterprise Server (GHES). This PR adds support for it within the existing \`github_enterprise\` integration. **The two differences:** 1. **Webhook host identification**: GHES sends \`X-GitHub-Enterprise-Host: hostname\`. GHE.com sends \`X-Github-Tenant: {slug}\` (no host header). \`get_host()\` now falls back to \`X-Github-Tenant\` and synthesises \`{tenant}.ghe.com\` as the host identifier. 2. **API base URL**: GHES exposes its API at \`https://{host}/api/v3/\`. GHE.com exposes it at \`https://api.{tenant}.ghe.com/\` (no \`/api/v3\` path prefix, API subdomain instead). The \`.ghe.com\` suffix is used as the discriminator everywhere: - \`client.py\`: \`base_url\` and \`build_url()\` skip the \`/api/v3\` rewrite for GHE.com - \`integration.py\`: new \`_api_base_url()\` helper used in \`get_user_info\` and \`_get_ghe_installation_info\` Existing GHES behaviour is unchanged. The \`X-GitHub-Enterprise-Host\` header takes precedence if both headers are somehow present. The webhook routing through hybrid cloud already works without changes — \`get_host()\` returns a host, \`external_id\` is stored as \`{host}:{installation_id}\` during \`build_integration\`, and \`urlparse(installation["account"]["html_url"]).netloc\` naturally extracts \`{tenant}.ghe.com\` from GHE.com payload URLs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub Enterprise Cloud with data residency (GHE.com, e.g. `acme-corp.ghe.com`) uses a different webhook header and API URL pattern than GitHub Enterprise Server (GHES). This PR adds support for it within the existing `github_enterprise` integration.
The two differences:
Webhook host identification: GHES sends `X-GitHub-Enterprise-Host: hostname`. GHE.com sends `X-Github-Tenant: {slug}` (no host header). `get_host()` now falls back to `X-Github-Tenant` and synthesises `{tenant}.ghe.com` as the host identifier.
API base URL: GHES exposes its API at `https://{host}/api/v3/`. GHE.com exposes it at `https://api.{tenant}.ghe.com/\` (no `/api/v3` path prefix, API subdomain instead). The `.ghe.com` suffix is used as the discriminator everywhere:
Existing GHES behaviour is unchanged. The `X-GitHub-Enterprise-Host` header takes precedence if both headers are somehow present.
The webhook routing through hybrid cloud already works without changes — `get_host()` returns a host, `external_id` is stored as `{host}:{installation_id}` during `build_integration`, and `urlparse(installation["account"]["html_url"]).netloc` naturally extracts `{tenant}.ghe.com` from GHE.com payload URLs.