State of Federation 2026Share your insights on GraphQL Federation.Take the Survey→

HubAPI Governance

API Governance that doesn't
slow you down.

Design APIs consumer-first, automate schema governance, and ship with confidence.

Start Governing Smarter See capabilities

The Problem

Your graph grows. Your teams stay siloed.

As GraphQL Federation scales across teams, ownership disappears, breaking changes reach production, and platform engineers become human routers.

See capabilities

"Who owns this entity?"

Teams ask the platform team who owns what. Platform engineers can field dozens of these routing questions a week.

Breaking changes in production

Deleted fields, renamed types — without traffic-aware validation, they break clients before anyone notices.

Service-first, not consumer-first

Teams design from inside their microservice, not from user needs. The graph reflects the org chart, not the product.

How It Works

From UI mock to reviewed proposal

Paste your UI mock

Drop a screenshot of your design (PNG, JPG, or a Figma screenshot) onto the canvas.

Build the dream query

Select the UI area and build the query. Create any missing fields inline.

Assign to subgraphs

Assign new fields to the right subgraph on the shared canvas.

Open a Proposal

Schema checks run, with a client-traffic check on breaking changes. Owners are auto-assigned as required reviewers.

Everything your graph needs to stay healthy

Protected main, required reviewers, client-traffic checks. Governance that scales.

Ownership

Logical and physical ownership, clearly separated

An Architect can own the User type — reviewing its schema quality — without owning the subgraph that resolves it. The Payroll subgraph's owners review any change to its fields. One change can need approval from both.

Stop asking who to talk to. One click on a type's shield icon shows its owners — so platform engineers stop being a human router.

Ownership Map

Assigned

User EntityArchitect

Payroll SubgraphPayroll owners

HR SubgraphHR owners

Shield icon shows owners on the canvas

Protected Main

Changes made in Hub go through a Proposal

Main is read-only in Hub and stays in sync with your production schema. Changes you make in Hub go through a Proposal — Hub's pull request for schema. Touch the Payroll subgraph? Its owners are added as required reviewers automatically. Unresolved threads block approval.

Approval is gated. Approve stays inactive until every check passes and every thread is resolved, and the proposal stays blocked until every required reviewer approves.

Proposal #42 · Add bonus fieldOpen

Composes

Pass

Breaking changes

Pass

Unresolved Threads

Pass

Awaiting: Payroll owners

Pending

Auto-assigned: Payroll subgraph owners

Safe Deletions

Traffic-aware deletion protection

When a proposal has a breaking change, such as a deleted field, the client traffic check fails it while real clients still use the field. It looks back 7 days by default and needs your router to send schema usage metrics, which it does by default. Graph pruning, if you enable it, also flags fields deleted without being deprecated first, with a configurable grace period. At Error severity, that fails the check.

Clients still use it → blocked. Deleted without @deprecated → flagged by pruning. Deprecated, no client traffic → allowed.

Deletion CheckphoneNumber

Clients still use fieldBlocked

Pruning: never deprecatedFlagged

Deprecated, no trafficAllowed

Traffic lookback: 7 days (default)

Query Intelligence

See if your changes actually improve the graph

Hub calculates complexity distribution across the operations in the collections you select and visualizes whether a schema change makes your graph more or less efficient. Reassign a field to another subgraph and see how average complexity and total fetches change.

Complexity Distribution

main branch

avg ↓ 11%

this branch

Example: main vs. this branch

Governance

Four pillars of graph protection

Hub automates the rules so your team catches breaking changes before approval.

Protected Main

You can't edit main directly in Hub. Changes made in Hub go through a Proposal.

Auto-Reviewer Assignment

Modify a subgraph or type and its owners are added as required reviewers automatically. No manual tagging.

Thread-Blocked Approval

Unresolved discussion threads block approval and show as a failing Hub check on the proposal.

Checks Before Approval

Composition, breaking changes, client traffic, lint and pruning errors, and linked namespaces run from Cosmo. Hub adds checks for unresolved threads and unassigned fields.

Enforcement

How Hub enforces review

Governance maps people to parts of the schema and controls approval at the proposal stage.

1You create a proposal from your branch.
2Hub analyzes the schema changes.
3It identifies the affected types and subgraphs.
4It adds their owners as required reviewers.
5The proposal stays blocked until every required reviewer approves. Unresolved discussion threads also block approval.

Graph admins

Can approve any proposal and manage governance settings. Keep this role to platform leads.

Type owners

Review any change to their type, whichever subgraph resolves it. Assign them to shared entities.

Subgraph owners

Review any change that assigns, removes, or modifies fields in their subgraph. Assign one to every service.

Limits. Governance doesn't restrict branch edits, assign implementation work, or apply across graphs. Every affected owner becomes a required reviewer, with no partial approval. Without owners assigned, proposals have no required reviewers.

Hub governance FAQ

How does Hub enforce owner review on federated schema changes?

When you create a proposal, Hub analyzes the schema changes, finds the affected types and subgraphs, and adds their owners as required reviewers. The proposal stays blocked until every required reviewer approves, even if all checks pass. Unresolved discussion threads also block approval.

What's the difference between a type owner and a subgraph owner?

A type owner reviews any change to their type, whichever subgraph resolves it. A subgraph owner reviews any change that assigns, removes, or modifies fields in their subgraph. The two are separate, so one change can need approval from both. Graph admins can approve any proposal.

What checks run on a proposal before it can be approved?

Integration checks from Cosmo: Composes, Breaking changes, Client traffic, Lint Errors, Pruning Errors, and Linked namespaces. Hub checks: Unresolved Threads and Unassigned Fields. The Approve button stays inactive until all checks pass and all discussions are resolved.

Does governance stop people editing branches?

No. Governance controls approval at the proposal stage, not editing. It doesn't restrict branch edits, assign implementation work, or apply across graphs.

What happens if no owners are assigned?

Proposals have no required reviewers, so anyone can approve anything. Assign owners once and Hub adds the right reviewers to every proposal that touches an owned type or subgraph.

Which Hub plans include governance?

Subgraph and type ownership and approval workflows are included in Hub Pro ($49 per user per month, with a 14-day trial) and Hub Enterprise. Proposals also need the graph connected to the Cosmo schema registry, with proposals configured in Cosmo.