Developer portals

Connecting a developer portal to GitHub workflows

A developer portal authorizes through the corporate directory; GitHub workflow orchestration authorizes through GitHub. Zekt Gate is the boundary between them, so Backstage or an internal developer portal can trigger orchestrated GitHub workflows using the identity your developers already sign in with — with every call attributable to a person, an application and a tenant.

The shape of the integration

The portal already has an Entra access token for the person using it. It calls the Zekt Gate API with that token, exactly as it would call any other enterprise API — no GitHub App to install for the caller, no token to mint, no credential to store in the portal.

Zekt Gate validates the token, resolves the customer, authorizes the operation and forwards the request to Zekt. What comes back is Zekt’s own answer, unchanged.

What the portal can do

Show what is available

Read the Zekt Directory to list the capabilities this customer may request — the same Directory the GitHub-native path uses, filtered by the same visibility rules.

Show how to call it

Read the Zekt Registry for the machine-readable contract: the accepted input parameters, which are mandatory, and which contract version is being consumed.

Request work

Declare one or more services in a single request and let Zekt orchestrate and correlate the runs. The portal does not sequence anything itself.

Attribute it

Every call carries the enterprise, the tenant, the user, the client application and the correlation — so the audit record names who asked, not merely that a gateway called.

Backstage specifically

Backstage is the portal most often named here, and nothing about Zekt Gate is tied to it. Gate exposes an ordinary HTTP API that accepts an Entra token; any portal, internal tool or service that can present one can call it.

That matters for the obvious reason — an internal portal is as valid a caller as Backstage — and for a less obvious one: a design that assumed Backstage would have grown Backstage-shaped assumptions, and the boundary would have been harder to reason about.

Self-service without a second identity

What your platform team avoids

Provisioning GitHub identities for people who only use the portal
Storing a long-lived GitHub credential inside the portal
Reconciling a portal’s idea of who someone is with GitHub’s
Explaining to a security reviewer why a shared account triggers production work

What stays exactly as it was

Your Entra tenant, its policies and its conditional access
The GitHub-native path — workflows calling Zekt directly are untouched
Zekt’s own service model: Directory, Registry, orchestration, correlation