For teams

Graphwake for platform and API governance teams

Last checked 2026-11-114 min read

Platform teams get asked who calls what, and asked to prevent the next cross-team API break, without owning the APIs in question. Graphwake gives you a dependency map that consumer teams keep current themselves, a breaking-change check on every pull request that shows which teams a change affects, and alerts that reach only those teams. You connect each service once; nobody maintains a consumer list.

ExampleGitHub Actions · pull request #1284
  • Check out code2s
  • Run tests41s
  • Graphwake spec check1s
  • graphwake: spec sent (pull request #1284)
  • Build1m 12s
Build passed
In Graphwake: impact 79 HighThe teams that consume the endpoints were told.

If Graphwake can’t be reached, the step logs it and exits cleanly. The build carries on.

One step sends the spec. It never blocks a build. GitHub Actions, GitLab CI, Azure DevOps, Bitbucket Pipelines and Jenkins.
On this page
  1. What you can stop doing
  2. If this endpoint changes, what is affected?
  3. Setup
  4. What Graphwake adds
  5. Answers inside your developers’ AI assistant
  6. When your current setup alone is enough
  7. Questions

What you can stop doing

TodayWith Graphwake
Keeping a consumer list in a wiki or a sheetConsumer teams subscribe to the endpoints they call, so the map stays current without you.
Posting API changes to a company-wide channelEach breaking change goes only to the subscribed teams, in their own Slack or Microsoft Teams channel, or by email.
Answering “who uses this endpoint?” by handThe service graph, the endpoint page or a developer’s AI assistant answers it from the same map.
Hunting for owners after a reorganisationOwners per service and per endpoint, with a weekly report of the gaps to admins.

If this endpoint changes, what is affected?

Every pull request that changes a spec is checked before the merge. The CI step sends the spec; Graphwake stores it as a draft that does not replace the live spec, compares the two, and shows the breaking changes, the teams that call each changed endpoint, and an impact score with its arithmetic. With alerts on open pull requests turned on, those teams hear about it while it is still a review comment. A new push updates the same alert, and a pull request closed without merging sends a cancelled notice.

ExampleService graph · orders-api
GET/orders/{id}2 consumer teams
Service
orders-api
Owner
payments-team

Consumers

  • checkout · 4 peopleSlack #team-checkout
  • mobile-app · 6 peopleSlack #mobile-alerts

Suggested by Discovery

  • storefront · uses a neighbouring endpointmaybe · 72
GET/orders/{id}/invoiceBlind spot

No team subscribes to this endpoint. A breaking change here reaches no subscribed team.

Who owns an endpoint, who consumes it, and where nobody is listening. A suggested team is added only when someone confirms it.

Setup

  1. Connect each spec

    A published spec URL, checked every 30 minutes, or one CI step in GitHub Actions, GitLab CI, Azure DevOps, Bitbucket Pipelines or Jenkins. Minutes to set up.

  2. Set owner teams

    One owner per service; an endpoint inherits it unless it has its own.

  3. Point alerts at team channels

    Each team chooses Slack, Microsoft Teams or email. Anyone can also follow a single endpoint by email.

  4. Invite the consumer teams

    Developers subscribe to the endpoints they call with one click. Discovery suggests the teams that probably call an endpoint but have not subscribed.

See who your next breaking change reaches.Paste a spec URL or add one CI step. 7-day free trial. Cancel before day 7 and you pay nothing.
Start free trial

What Graphwake adds

  • A team-level map

    Owner, endpoints and consumer teams for every service, as a graph or a table.

  • An impact score you can explain

    10 per breaking change (up to 30), 12 per affected team (up to 36), 1 per person (up to 14), 10 per blind spot (up to 20). The rules are public.

  • Append-only history

    Every change, alert, subscription and ownership decision, with who and when.

  • Discovery for unmapped endpoints

    Rule-based suggestions of teams likely to be affected, each with a reason and a confidence. Someone confirms before a team is subscribed.

Answers inside your developers’ AI assistant

Graphwake MCP lets developers ask who owns or consumes an endpoint, what their team depends on, and what a local spec would break, without opening the dashboard. Works with Claude Code, Cursor, GitHub Copilot and other clients that accept an API key. Keys are read-only unless you allow writes, a member can act only for their own team, and admin work is never reachable from an assistant. Setup guide.

Good to know

When your current setup alone is enough

  • Every caller lives in one repository. A code search for the path finds most consumers, and the author can ping them.
  • Consumers already run contract tests. If every consumer team writes and maintains them, a break shows up in their pipeline; Graphwake still tells them before the merge without test code.

For the wider governance picture, read API governance across many teams. For the CI side on its own, read OpenAPI diff in CI.

Questions

Which CI systems does Graphwake support?

GitHub Actions, GitLab CI, Azure DevOps, Bitbucket Pipelines and Jenkins. Without CI, give Graphwake your spec’s published URL and it checks it every 30 minutes.

What happens if a team never subscribes?

Its endpoints show up as orphans on the map and in the weekly report, and a breaking change on one counts as a blind spot in the impact score. Discovery suggests the teams that probably call it.

Does Graphwake read our code?

No. Graphwake reads your spec, not your code. The CI step sends only the OpenAPI file.

Where does Graphwake run?

Our cloud or your own servers. Running Graphwake on your own servers is an Enterprise option.

Pick an endpoint. See who it reaches. 7-day free trial. Cancel before day 7 and you pay nothing.

Start free trial