Teams & ownership
postman-app is built by 25+ teams across Postman. Understanding how they're organized helps you know who to ask when you have a question, whose review you need on a PR, and how code ownership is enforced.
Two kinds of teams
Teams in postman-app fall into two categories with very different jobs:
Platform teams
Platform teams build the infrastructure that other teams use. Their code is not a user-facing feature — it's the foundation that makes features possible. Platform team work shows up everywhere, but users never see it labeled as such.
| Team | What they own |
|---|---|
| Web Platform / Client Productivity | Build tooling (Rspack config), analytics service, service worker, Nx generators, CI/CD pipelines |
| Client SDK | Dock engine, sidebar engine, navigation, multi-entity components, workspace data layer |
| Client Build and Release (Client Distribution) | Daily releases, packaging pipeline, GitHub Actions, Node/Yarn upgrades, CI performance |
| Test Infrastructure | E2E infrastructure (Playwright setup), test utilities, CI test jobs |
| Desktop Platform | Electron main process, IPC channels, native integrations |
| UX Foundation | Base styles, global UI components, theming, text editor |
If you're building a new feature and something in the infrastructure feels broken or missing — slow CI, a confusing Nx generator, a flaky test setup — platform teams are who to talk to.
Feature teams
Feature teams build the product capabilities that users actually use. Each team owns one or more product areas.
| Team | What they build |
|---|---|
| API Client | HTTP workbench (request/response editor), runtime REPL, request sending |
| Collections | Collections sidebar, collection management, collection runner |
| Runtime | Request execution engine, Postman Agent, visualizer sandbox |
| Collaboration / Collaboration Core | Workspaces, workspace overview, real-time collaboration, comments |
| API Design | API Builder, OpenAPI editor, spec management |
| API Dev Platform | Developer platform features |
| API Mock | Mock server creation and management |
| API Network | API Network, public API discovery, Private API Network |
| API Security | Security scanning, vault, secrets management, MFA |
| Automation Testing | Collection Runner, test scripts, test execution |
| Performance Testing | Load testing, performance test runs |
| IAM | Identity, authentication, user management, teams, SSO |
| Billing | Subscription management, plan enforcement |
| Documentation | API documentation generation (Scribe) |
| Monitoring | Collection monitors, scheduled runs |
| Search | Universal search, request tab completions |
| Version Control | Git-based version control for collections |
| Integrations Platform | Third-party integrations (Slack, GitHub, etc.) |
| Onboarding & Notifications | New user flows, in-app notifications |
| Partnerships & Ecosystem | Extension platform, partner integrations |
How ownership is enforced: CODEOWNERS
Every file in postman-app has an owner. Ownership is defined in .github/CODEOWNERS. When you open a PR that touches a file, GitHub automatically requests a review from that file's owner.
# Example from .github/CODEOWNERS
# Web Platform owns the build config
config/rspack @postman-eng/client-sdk
config/webpack @postman-eng/web-platform
nx.json @postman-eng/web-platform
tools/generator @postman-eng/web-platform
# Client SDK owns dock and navigation
libs/dock-engine @postman-eng/client-sdk
libs/dock-constants @postman-eng/client-sdk
# Runtime team owns the request runner
src/renderer/runtime-repl @postman-eng/http-api-client-devs
src/postman-agent @postman-eng/http-api-client-devs
This is not just for notifications — it's a code quality gate. A PR touching a platform team's infrastructure code needs their explicit approval before it can merge. This prevents accidental breakage of shared foundations.
How to find who owns a piece of code
Three ways, from fastest to most thorough:
1. Check CODEOWNERS
# Find who owns a specific file
cat .github/CODEOWNERS | grep "data/workspace-data"
2. Use git blame
git log --oneline -5 data/workspace-data/src/store.ts
# Look at the commit messages for JIRA ticket IDs
# Search the JIRA ticket to find the team
3. Look at the Nx tags in project.json
# Every package has a 'scope' tag that maps to a team
cat data/workspace-data/project.json | grep scope
# Output: "scope:collaboration"
# That means the Collaboration team owns this package
The platform vs feature team relationship
In practice, feature teams and platform teams have a clear division of responsibility:
Feature teams produce: The visible functionality — what users click, see, and experience. Collections sidebar, request editor, workspace page, API builder.
Platform teams produce: The invisible infrastructure — what makes features possible. The build system, the gateway client, the sidebar engine, the state management patterns, the CI pipeline.
Feature teams consume platform team tools. Platform teams support feature teams. When a feature team needs something that doesn't exist yet in the platform, they either build a temporary solution or work with the platform team to add it properly.
This is also why some code looks more polished than other code. Platform team code is shared by dozens of features — it's carefully designed, well-documented, and rigorously tested. Feature team code in ui-features/ or src/renderer/ is often more pragmatic — it was built quickly to ship a feature and may have more technical debt.
When you're unsure who to ask
- Slack: Post in
#app-devor#desktop-platform-eng— someone will route you to the right team - CODEOWNERS — mechanical but accurate
- Your team lead — they know the human map of the codebase better than any file
- The team-resources page — links to key Confluence pages for specific teams
One thing to know: at Postman, it's normal to ask questions across team boundaries. The codebase is interconnected. Asking a Collaboration team member about runtime behavior, or asking the Web Platform team about a bundling issue — this is expected and encouraged. There are no silos.