Designed for teams who build APIs and the people who work alongside them.
We wrote our curriculum with specific roles in mind. Not because people in other roles cannot benefit, but because clarity about who we are teaching shapes how we explain things. You will recognize your situation in what we describe below.
You shape the product but not always the API surface.
Product managers often sit in the gap between business requirements and technical implementation. API design decisions happen in that gap, and without shared language, it is difficult to contribute meaningfully to them. We help you develop the vocabulary and conceptual frameworks to participate in API design conversations, ask questions that surface real tradeoffs, and recognize when a design decision is likely to create problems at scale.
You do not need to write API specifications. You need to understand what makes them good or fragile, and why.
You design APIs every day, often without a structured review process.
Industry research suggests that API inconsistencies are most commonly introduced not through carelessness but through the absence of a shared review standard. Engineers make reasonable local decisions that compound into global inconsistencies over time.
Our framework gives you a structured way to review your own work and your colleagues' work before it ships. The goal is not to add process for its own sake, but to catch the decisions that will become expensive to reverse later.
Documentation quality depends on understanding design intent.
Technical writers who understand the reasoning behind an API design write documentation that communicates intent, not just behavior. When a resource is named a certain way because of a specific architectural decision, that context belongs somewhere in the documentation. Without it, users reverse-engineer the design from the docs, often incorrectly.
We help technical writers develop enough API design literacy to ask the right questions of engineers and produce documentation that holds up over multiple API versions.
Situations where teams find this work useful.
Your API has grown across multiple teams and you are noticing naming or structure inconsistencies that were not there at the start.
You are planning a major version bump and want to understand what a thoughtful deprecation process actually looks like before you commit to a timeline.
Your documentation is accurate but integration partners still raise questions that suggest something is missing from how the API is explained.
You have a style guide for your API but nobody quite agrees on how to apply it in ambiguous cases, and the debates are slowing down reviews.
Recognize your team in any of these?
A conversation about your current API design process is the best way to figure out whether our approach is a good fit for where you are right now.