Describe the feature or problem you'd like to solve

gh lets you configure which GitHub host to use, but the API endpoint is always derived from that host — there's no way to route API traffic to a different endpoint.

Virtually every other tool in the GitHub ecosystem already treats the API endpoint as a separate configuration:

• GitHub Actions — GITHUB_API_URL is independent from GITHUB_SERVER_URL
• Octokit JS — baseUrl option
• Octokit Ruby — api_endpoint option
• PyGithub — base_url parameter
• go-github — NewEnterpriseClient()

gh is the last commonly used tool in the ecosystem that doesn't let you configure where API requests go.

This matters in practice when an organization runs an API gateway or reverse proxy in front of GitHub — for access logging, rate-limit visibility, or request-level monitoring. Web UI and git clone/push traffic can stay on the canonical hostname (OAuth/SSO callbacks are host-bound, and git remotes work as-is), but API traffic is machine-to-machine and can be routed through a different endpoint. Every API client can be pointed at the gateway except gh.

It's especially relevant for GHEC data-residency tenants, where the *.ghe.com DNS zone is GitHub-managed and the organization has no control over the api.* hostname — routing API calls through a different endpoint is the only option, and gh doesn't support it.

Proposed solution

Add an optional API endpoint override to the per-host configuration in hosts.yml:

example.ghe.com:
    user: pete
    api_host: api-gateway.example.net

When set, gh sends REST and GraphQL requests to that host instead of the derived default. Authentication is unchanged. When not set, behavior is identical to today.

Additional context

Workarounds that people try today don't hold up:

• git config url.*.insteadOf — only applies to git transport; gh's API HTTP client doesn't read it (see #12916)
• Forking gh — works but means tracking every upstream release indefinitely across all platforms

The derivation logic lives in internal/ghinstance/host.go (RESTPrefix, GraphQLEndpoint) — the change seems contained. The api_host field above is one possible shape; we're open to whatever approach fits gh's config model best as long as there's a way to route API traffic to a different endpoint. We use gh at scale and are happy to contribute a PR if the maintainers are on board with the direction.