Team API

Team Topologies Organizational Design

A team without a clear interface is a team everyone has to interrupt to work with. A Team API makes collaboration self-service.

Overview

A Team API is how a team defines its interface to the rest of the organization. It goes well beyond code: a complete Team API covers technical interfaces, communication preferences, documentation, support models, and ways of working. The concept enables true X-as-a-Service interaction by making a team’s boundaries explicit and self-service.

A well-defined Team API includes:

Code & service interfaces — REST APIs, GraphQL, message queues, consumable front-end components, SLAs (e.g., 99.9% uptime, <200ms p95 latency)
Communication preferences — which Slack channel, email response times, office hours, meeting-free days
Documentation & onboarding — where docs live, getting-started guide (<15 min), runbooks and support resources
Support model — office hours schedule, on-call rotation, escalation path, priority-based SLAs
Ways of working — PR review process, deployment windows, breaking change notice period

The key insight is that this goes way beyond a technical API. A team that publishes clear interfaces but has no onboarding path, no support model, and no communication norms is not actually self-service; consumers still need to track people down and figure things out through personal favors. The Team API makes the full interaction contract explicit.

Resources

Three Team Interaction Modes — Team APIs enable clean X-as-a-Service interactions
Team Topologies — the framework where this concept originates
C4 Model — a complementary way to draw the architecture a Team API exposes