Before building anything, define your API's value, users, and business goals from day one.
Many organizations think of APIs as tech projects, not products. The result? Confused consumers, poor adoption, and wasted effort.
This station helps you define your API’s purpose, target audience, and success criteria, so teams can deliver APIs that solve real problems.
Ensure your API is discoverable, understandable, and usable — before and after launch.
Great APIs don’t just work — they feel intuitive. Whether your consumer is an internal developer, external partner, or AI agent, their experience determines adoption.
Without a clear experience plan:
- Great APIs go unused
- Teams waste time guessing how to use your API
- Feedback loops are broken or missing.
This station helps you see your API through the eyes of its consumers.
Ensure scalability, reuse, and governance across your API and platform components.
When APIs scale across teams, your platform must enable governance and reuse without blocking speed. This station shows how to architect APIs for longevity, security, and efficiency.
Create API designs that are consistent, reusable, and grounded in business intent and shared standards.
Designing APIs is not just about naming endpoints. Good design ensures APIs are usable, consistent, and aligned with business and technical goals. Poor design leads to tight coupling, low reuse, and costly rework across teams.
Build, test, and release APIs using modern delivery pipelines and engineering best practices.
Even the best API designs fail if delivery is inconsistent. This station ensures your APIs are built with quality, tested thoroughly, and deployed reliably — enabling faster iterations and greater confidence.
Validate that APIs meet business, design, and operational standards before release.
APIs are long-lived products and must meet expectations for quality, consistency, and compliance. The audit connects design decisions, implementation, and operational readiness to defined standards, reducing risk before exposure.
Expose APIs securely and clearly to the right audience with the right documentation and processes.
Publishing is more than deploying — it’s about discoverability, access, and support. If APIs aren't published correctly, they won’t be used, reused, or secured effectively.
Use metrics and feedback to track API performance and drive continuous improvement.
API delivery doesn’t stop at launch. Without monitoring, teams can’t improve adoption, performance, or ROI. This station ensures APIs remain useful, secure, and evolving with business needs.
Publish this cycle
Export the page-specific template after reviewing the entity summary and supporting details above.
Publishing
Markdown and Confluence export
Use Markdown for repositories and static sites, or Confluence-wiki markup for compatible Confluence pages.
Markdown
# API Productization Cycle question template
The API-focused APIOps Cycles journey for productizing, designing, delivering, publishing, and improving APIs.
Use this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.
## 1. API Product Strategy
Before building anything, define your API's value, users, and business goals from day one.
### Canvas questions
#### Customer Journey Canvas
What journey does the most external meaningful customer experience, and what should improve?
- **Persona**: Who is the typical customer experiencing this journey?
- **Customer Discovers Need**: How does the customer recognize their need or problem?
- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?
- **Journey Steps**: What are the steps the customer takes in their journey?
- **Pains**: What are the customer's pain points or challenges?
- **Gains**: What are the customer's gains or benefits?
- **Inputs & Outputs**: What are the inputs and outputs at each step?
- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?
- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?
#### Domain Canvas
What are the core entities and business rules related to this capability or domain?
- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?
- **Core Entities & Business Meaning**: What are the core entities and their business meaning?
- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?
- **Relationships Between Entities**: What are the relationships between the entities?
- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?
- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?
#### API Value Proposition Canvas
How does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?
- **Tasks**: What are the customers (end-users) trying to achieve?
- **Gain Enabling Features**: What features enable end-users and API consumers to achieve gains?
- **Pain Relieving Features**: What features help end-users and API consumers overcome pains?
- **API Products**: What API products and features address the tasks, pains, and gains?
#### API Business Model Canvas
How feasible and reusable will this API be? Do we have a business case from a cost - benefit point of view?
- **API Value Proposition**: Start with one sticky note naming the API or API family, then capture what value the API offers to API consumers.
- **API Consumer Segments**: Who are the target audiences for the API?
- **Developer Relations**: How does the API provider reach and support API consumers?
- **Channels**: Through which mechanisms do API consumers interact with the API?
- **Key Resources**: What unique strategic assets must the API provider acquire or build?
- **Key Activities**: What are the most important actions the API provider must take to operate successfully?
- **Key Partners**: Who are the key stakeholders involved?
- **Benefits**: What are the significant benefits or revenue streams generated by the API?
- **Costs**: What are the significant costs involved in building, deploying, and operating the API?
### Before this station
- [ ] Capability opportunity is identified and documented.
- [ ] Consumer segments are identified.
### Ready to leave when
- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
- [ ] Business goals are defined.
- [ ] Market research identifies capability opportunities.
- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
## 2. API Consumer Experience
Ensure your API is discoverable, understandable, and usable — before and after launch.
### Canvas questions
#### API Value Proposition Canvas
How does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?
- **Tasks**: What are the customers (end-users) trying to achieve?
- **Gain Enabling Features**: What features enable end-users and API consumers to achieve gains?
- **Pain Relieving Features**: What features help end-users and API consumers overcome pains?
- **API Products**: What API products and features address the tasks, pains, and gains?
#### Customer Journey Canvas
What journey does the most external meaningful customer experience, and what should improve?
- **Persona**: Who is the typical customer experiencing this journey?
- **Customer Discovers Need**: How does the customer recognize their need or problem?
- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?
- **Journey Steps**: What are the steps the customer takes in their journey?
- **Pains**: What are the customer's pain points or challenges?
- **Gains**: What are the customer's gains or benefits?
- **Inputs & Outputs**: What are the inputs and outputs at each step?
- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?
- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?
### Before this station
- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
- [ ] Business goals are defined.
- [ ] Market research identifies capability opportunities.
- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
### Ready to leave when
- [ ] Capability opportunity is identified and documented.
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
### Other related resources
- **API Onboarding Best Practices**: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.
## 3. API Platform Architecture
Ensure scalability, reuse, and governance across your API and platform components.
### Canvas questions
#### Business Impact Canvas
What value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?
- **Expected benefits**: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?
- **Operational efficiency impact**: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?
- **Customer and employee impact**: How will customers, employees, partners, operators, or support teams experience the change?
- **Financial impact**: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?
- **Compliance and strategic impact**: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?
- **Impact of not proceeding**: What happens if the capability, automation, integration, or service is not improved or delivered?
- **Risks and criticality**: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?
- **Mitigations and decision impact**: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?
#### Location Canvas
What geopolitical, regulatory, network, and trust boundaries affect this capability or integration?
- **Location / Trust Groups**: What are the relevant geopolitical, regulatory, network, or trust groups?
- **Group Characteristics**: What are the characteristics of those groups, such as residency, trust level, or network exposure?
- **Relevant Locations / Zones**: What are the relevant locations, zones, or environments within each group?
- **Location / Zone Characteristics**: What are the characteristics of those locations or zones, such as ownership, region, or exposure?
- **Network / Regulatory Distances**: What latency, trust, regulatory, or connectivity distances exist between the locations?
- **Distance Characteristics**: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?
- **Connectivity Endpoints**: What connectivity endpoints or interfaces are associated with the locations?
- **Endpoint Access Characteristics**: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?
#### Capacity Canvas
How much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?
- **Current Business Volumes**: What are the current business volumes and transaction rates?
- **Future Consumption Trends**: What are the anticipated future consumption trends?
- **Peak Load and Availability Requirements**: What are the peak load and availability requirements?
- **Caching Strategies**: What caching strategies can be used to optimize performance?
- **Rate Limiting Strategies**: What rate limiting strategies can be used to manage consumption?
- **Scaling Strategies**: What scaling strategies can be used to accommodate growth?
### Before this station
- [ ] Capability opportunity is identified and documented.
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
### Ready to leave when
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
### Other related resources
- **API Metrics And Analytics**: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.
## 4. API Design
Create API designs that are consistent, reusable, and grounded in business intent and shared standards.
### Canvas questions
#### Domain Canvas
What are the core entities and business rules related to this capability or domain?
- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?
- **Core Entities & Business Meaning**: What are the core entities and their business meaning?
- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?
- **Relationships Between Entities**: What are the relationships between the entities?
- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?
- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?
#### Interaction Canvas
What kinds of interactions should this capability support before choosing a protocol-specific design?
- **CRUD Interactions**: Are CRUD (Create, Read, Update, Delete) interactions needed here?
- **CRUD Input & Output Models**: What are the input and output models for the CRUD interactions, if this style is needed?
- **CRUD Processing & Validation**: What are the processing and validation rules for the CRUD interactions, if this style is needed?
- **Query-Driven Interactions**: What read or query interactions are needed to answer consumer questions?
- **Query-Driven Input & Output Models**: What are the input and output models for the query-driven interactions?
- **Query-Driven Processing & Validation**: What are the processing and validation rules for the query-driven interactions?
- **Command-Driven Interactions**: What state-changing commands are needed, if any?
- **Command-Driven Input & Output Models**: What are the input and output models for the command-driven interactions, if this style is needed?
- **Command-Driven Processing & Validation**: What are the processing and validation rules for the command-driven interactions, if this style is needed?
- **Event-Driven Interactions**: What events need to be published or consumed, if any?
- **Event-Driven Input & Output Models**: What are the input and output models for the event-driven interactions, if this style is needed?
- **Event-Driven Processing & Validation**: What are the processing and validation rules for the event-driven interactions, if this style is needed?
#### REST Canvas
How can the API be designed using RESTful principles?
- **API Resources**: What are the key resources exposed by the API?
- **API Resource Model**: What is the structure of the API resource model?
- **API Verbs**: What HTTP verbs are used to interact with the API resources?
- **API Verb Example**: Provide an example of an API request and response for each verb.
#### Event Canvas
What events are relevant to the integration capability, and how are they produced, consumed, processed, and governed?
- **User Task / Trigger**: What user action or system event triggers this event operation?
- **Input / Event Payload**: What data is included in the incoming event payload? Specify key attributes.
- **Processing / Logic**: Describe the backend processing logic, including validations, transformations, or routing decisions.
- **Output / Event Result**: What resulting event or acknowledgment is produced? Include attributes of the output payload.
#### GraphQL Canvas
How can the API be designed using GraphQL principles?
- **API Name**: What is the name of the GraphQL API or endpoint?
- **Consumer Goals**: What problems are API consumers trying to solve? What data do they need?
- **Key Types**: What are the core types exposed (e.g., User, Order, Product)?
- **Relationships**: How do types relate to each other in nested queries?
- **Queries**: What common queries should be supported?
- **Mutations**: What operations will modify data (e.g., create, update, delete)?
- **Subscriptions**: Are there any real-time updates or events consumers can subscribe to?
- **Authorization Rules**: Who can access which fields or types?
- **Consumer Constraints**: Are there pagination, filtering, or rate-limiting constraints?
- **Notes / Open Questions**: Any pending decisions or integration considerations?
### Before this station
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
### Ready to leave when
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
### Other related resources
- **API Design Principles**: A concise guide to API usability, discoverability, and consistency grounded in shared design rules and real consumer needs.
- **Contract-First Capability Design**: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.
## 5. API Delivery
Build, test, and release APIs using modern delivery pipelines and engineering best practices.
### Station questions
- Use API Development Best Practices as guidance for implementing the validated contract with established frameworks and libraries, ensuring the result is reusable and maintainable.
- Build the API implementation from the validated contract using established frameworks, libraries, and team standards.
- Test APIs for functionality, security, and performance using automated testing tools.
- Use CI/CD pipelines to automate build, test, and deployment processes, ensuring consistent quality and traceability.
- Ensure APIs meet security and compliance requirements through automated checks and audits.
- Use the API Audit Checklist to ensure the API meets functional and non-functional requirements, including security, performance, and compliance.
- Deliver coding frameworks, libraries, and standards for API implementation. Implement CI/CD pipelines, quality assurance frameworks, and deployment automation tools.
- Even the best API designs fail if delivery is inconsistent. This station ensures your APIs are built with quality, tested thoroughly, and deployed reliably — enabling faster iterations and greater confidence.
### Before this station
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
### Ready to leave when
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
### Other related resources
- **API Development Best Practices**: Implementation guidance for turning a validated API interface contract into a consistent, maintainable API codebase using standard libraries, reusable patterns, and aligned development workflows.
- **API Testing Best Practices**: Guidelines for implementing automated functional, performance, and security testing throughout the API lifecycle.
- **APIOps CI/CD For APIs**: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.
- **API Security Best Practices**: A set of actionable controls for securing APIs, including authentication, authorization, encryption, rate-limiting, and pipeline-level compliance checks.
## 6. API Audit
Validate that APIs meet business, design, and operational standards before release.
### Station questions
- Conduct audits to ensure APIs meet organizational, technical, and legal standards before release.
- Use checklists, linters, and testing tools to verify consistency and conformance with standards.
- Collaborate with governance teams and domain experts to ensure APIs are ready for production.
- Establish a consistent audit process that evaluates API readiness across lifecycle stages using defined criteria, evidence, and standards. Ensure gaps are identified early and resolved before release.
- APIs are long-lived products and must meet expectations for quality, consistency, and compliance. The audit connects design decisions, implementation, and operational readiness to defined standards, reducing risk before exposure.
### Before this station
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
### Ready to leave when
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
- [ ] The interface design follows agreed design standards and conventions.
- [ ] The interface contract has been validated and tested against functional and non-functional requirements.
### Other related resources
- **API Audit Checklist**: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.
- **API Compliance Best Practices**: Ensure APIs meet legal, regulatory, and internal compliance through documentation, controls, and automated validations.
## 7. API Publishing
Expose APIs securely and clearly to the right audience with the right documentation and processes.
### Station questions
- Publish APIs to the appropriate gateways and environments to support reusability for multiple API consumers.
- Document how consumers find and use the API, including onboarding processes and registration.
- Ensure security models, gateway configuration, and legal terms are clear and accessible to consumers.
- Enable APIs to be published to the relevant environment and have clear registration and access mechanisms (e.g., API keys, OAuth, subscription plans) depending on the API consumer segments and security and compliance requirements.
- Publishing is more than deploying — it’s about discoverability, access, and support. If APIs aren't published correctly, they won’t be used, reused, or secured effectively.
### Before this station
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
- [ ] The interface design follows agreed design standards and conventions.
- [ ] The interface contract has been validated and tested against functional and non-functional requirements.
### Ready to leave when
- [ ] The solution passes quality, security, compliance, and readiness checks.
- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
- [ ] The capability is ready to be published or released through the selected delivery mechanism.
- [ ] Consumer-facing documentation and onboarding materials are ready.
### Other related resources
- **APIOps CI/CD For APIs**: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.
- **API Onboarding Best Practices**: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.
- **API Audit Checklist**: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.
## 8. API Monitoring & Improvement
Use metrics and feedback to track API performance and drive continuous improvement.
### Station questions
- Monitor performance metrics (e.g., API calls, latency, error rates) and adoption metrics (e.g., NPS).
- Analyze API usage metrics and incorporate user feedback into API iterations.
- Establish a habit of reviewing metrics and planning continuous improvement activities.
- Set up analytics frameworks to track performance and engagement. Develop feedback loops, analytics tools, and engagement strategies for APIs.
- API delivery doesn’t stop at launch. Without monitoring, teams can’t improve adoption, performance, or ROI. This station ensures APIs remain useful, secure, and evolving with business needs.
### Before this station
- [ ] The solution passes quality, security, compliance, and readiness checks.
- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
- [ ] The capability is ready to be published or released through the selected delivery mechanism.
- [ ] Consumer-facing documentation and onboarding materials are ready.
### Ready to leave when
- [ ] Consumer-facing documentation and onboarding materials are ready.
- [ ] Consumer onboarding, support, and communication processes are ready.
- [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.
### Other related resources
- **API Metrics And Analytics**: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.
- **API Community Engagement Strategies**: A playbook for fostering API adoption by cultivating communities through content, support channels, feedback loops, and social engagement strategies.
Confluence-wiki
h1. API Productization Cycle question template
The API-focused APIOps Cycles journey for productizing, designing, delivering, publishing, and improving APIs.
Use this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.
h2. 1. API Product Strategy
Before building anything, define your API's value, users, and business goals from day one.
h3. Canvas questions
h4. Customer Journey Canvas
What journey does the most external meaningful customer experience, and what should improve?
* *Persona*: Who is the typical customer experiencing this journey?
* *Customer Discovers Need*: How does the customer recognize their need or problem?
* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?
* *Journey Steps*: What are the steps the customer takes in their journey?
* *Pains*: What are the customer's pain points or challenges?
* *Gains*: What are the customer's gains or benefits?
* *Inputs & Outputs*: What are the inputs and outputs at each step?
* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?
* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?
h4. Domain Canvas
What are the core entities and business rules related to this capability or domain?
* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?
* *Core Entities & Business Meaning*: What are the core entities and their business meaning?
* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?
* *Relationships Between Entities*: What are the relationships between the entities?
* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?
* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?
h4. API Value Proposition Canvas
How does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?
* *Tasks*: What are the customers (end-users) trying to achieve?
* *Gain Enabling Features*: What features enable end-users and API consumers to achieve gains?
* *Pain Relieving Features*: What features help end-users and API consumers overcome pains?
* *API Products*: What API products and features address the tasks, pains, and gains?
h4. API Business Model Canvas
How feasible and reusable will this API be? Do we have a business case from a cost - benefit point of view?
* *API Value Proposition*: Start with one sticky note naming the API or API family, then capture what value the API offers to API consumers.
* *API Consumer Segments*: Who are the target audiences for the API?
* *Developer Relations*: How does the API provider reach and support API consumers?
* *Channels*: Through which mechanisms do API consumers interact with the API?
* *Key Resources*: What unique strategic assets must the API provider acquire or build?
* *Key Activities*: What are the most important actions the API provider must take to operate successfully?
* *Key Partners*: Who are the key stakeholders involved?
* *Benefits*: What are the significant benefits or revenue streams generated by the API?
* *Costs*: What are the significant costs involved in building, deploying, and operating the API?
h3. Before this station
* [ ] Capability opportunity is identified and documented.
* [ ] Consumer segments are identified.
h3. Ready to leave when
* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
* [ ] Business goals are defined.
* [ ] Market research identifies capability opportunities.
* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
h2. 2. API Consumer Experience
Ensure your API is discoverable, understandable, and usable — before and after launch.
h3. Canvas questions
h4. API Value Proposition Canvas
How does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?
* *Tasks*: What are the customers (end-users) trying to achieve?
* *Gain Enabling Features*: What features enable end-users and API consumers to achieve gains?
* *Pain Relieving Features*: What features help end-users and API consumers overcome pains?
* *API Products*: What API products and features address the tasks, pains, and gains?
h4. Customer Journey Canvas
What journey does the most external meaningful customer experience, and what should improve?
* *Persona*: Who is the typical customer experiencing this journey?
* *Customer Discovers Need*: How does the customer recognize their need or problem?
* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?
* *Journey Steps*: What are the steps the customer takes in their journey?
* *Pains*: What are the customer's pain points or challenges?
* *Gains*: What are the customer's gains or benefits?
* *Inputs & Outputs*: What are the inputs and outputs at each step?
* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?
* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?
h3. Before this station
* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
* [ ] Business goals are defined.
* [ ] Market research identifies capability opportunities.
* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
h3. Ready to leave when
* [ ] Capability opportunity is identified and documented.
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h3. Other related resources
* *API Onboarding Best Practices*: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.
h2. 3. API Platform Architecture
Ensure scalability, reuse, and governance across your API and platform components.
h3. Canvas questions
h4. Business Impact Canvas
What value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?
* *Expected benefits*: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?
* *Operational efficiency impact*: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?
* *Customer and employee impact*: How will customers, employees, partners, operators, or support teams experience the change?
* *Financial impact*: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?
* *Compliance and strategic impact*: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?
* *Impact of not proceeding*: What happens if the capability, automation, integration, or service is not improved or delivered?
* *Risks and criticality*: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?
* *Mitigations and decision impact*: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?
h4. Location Canvas
What geopolitical, regulatory, network, and trust boundaries affect this capability or integration?
* *Location / Trust Groups*: What are the relevant geopolitical, regulatory, network, or trust groups?
* *Group Characteristics*: What are the characteristics of those groups, such as residency, trust level, or network exposure?
* *Relevant Locations / Zones*: What are the relevant locations, zones, or environments within each group?
* *Location / Zone Characteristics*: What are the characteristics of those locations or zones, such as ownership, region, or exposure?
* *Network / Regulatory Distances*: What latency, trust, regulatory, or connectivity distances exist between the locations?
* *Distance Characteristics*: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?
* *Connectivity Endpoints*: What connectivity endpoints or interfaces are associated with the locations?
* *Endpoint Access Characteristics*: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?
h4. Capacity Canvas
How much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?
* *Current Business Volumes*: What are the current business volumes and transaction rates?
* *Future Consumption Trends*: What are the anticipated future consumption trends?
* *Peak Load and Availability Requirements*: What are the peak load and availability requirements?
* *Caching Strategies*: What caching strategies can be used to optimize performance?
* *Rate Limiting Strategies*: What rate limiting strategies can be used to manage consumption?
* *Scaling Strategies*: What scaling strategies can be used to accommodate growth?
h3. Before this station
* [ ] Capability opportunity is identified and documented.
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h3. Ready to leave when
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h3. Other related resources
* *API Metrics And Analytics*: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.
h2. 4. API Design
Create API designs that are consistent, reusable, and grounded in business intent and shared standards.
h3. Canvas questions
h4. Domain Canvas
What are the core entities and business rules related to this capability or domain?
* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?
* *Core Entities & Business Meaning*: What are the core entities and their business meaning?
* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?
* *Relationships Between Entities*: What are the relationships between the entities?
* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?
* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?
h4. Interaction Canvas
What kinds of interactions should this capability support before choosing a protocol-specific design?
* *CRUD Interactions*: Are CRUD (Create, Read, Update, Delete) interactions needed here?
* *CRUD Input & Output Models*: What are the input and output models for the CRUD interactions, if this style is needed?
* *CRUD Processing & Validation*: What are the processing and validation rules for the CRUD interactions, if this style is needed?
* *Query-Driven Interactions*: What read or query interactions are needed to answer consumer questions?
* *Query-Driven Input & Output Models*: What are the input and output models for the query-driven interactions?
* *Query-Driven Processing & Validation*: What are the processing and validation rules for the query-driven interactions?
* *Command-Driven Interactions*: What state-changing commands are needed, if any?
* *Command-Driven Input & Output Models*: What are the input and output models for the command-driven interactions, if this style is needed?
* *Command-Driven Processing & Validation*: What are the processing and validation rules for the command-driven interactions, if this style is needed?
* *Event-Driven Interactions*: What events need to be published or consumed, if any?
* *Event-Driven Input & Output Models*: What are the input and output models for the event-driven interactions, if this style is needed?
* *Event-Driven Processing & Validation*: What are the processing and validation rules for the event-driven interactions, if this style is needed?
h4. REST Canvas
How can the API be designed using RESTful principles?
* *API Resources*: What are the key resources exposed by the API?
* *API Resource Model*: What is the structure of the API resource model?
* *API Verbs*: What HTTP verbs are used to interact with the API resources?
* *API Verb Example*: Provide an example of an API request and response for each verb.
h4. Event Canvas
What events are relevant to the integration capability, and how are they produced, consumed, processed, and governed?
* *User Task / Trigger*: What user action or system event triggers this event operation?
* *Input / Event Payload*: What data is included in the incoming event payload? Specify key attributes.
* *Processing / Logic*: Describe the backend processing logic, including validations, transformations, or routing decisions.
* *Output / Event Result*: What resulting event or acknowledgment is produced? Include attributes of the output payload.
h4. GraphQL Canvas
How can the API be designed using GraphQL principles?
* *API Name*: What is the name of the GraphQL API or endpoint?
* *Consumer Goals*: What problems are API consumers trying to solve? What data do they need?
* *Key Types*: What are the core types exposed (e.g., User, Order, Product)?
* *Relationships*: How do types relate to each other in nested queries?
* *Queries*: What common queries should be supported?
* *Mutations*: What operations will modify data (e.g., create, update, delete)?
* *Subscriptions*: Are there any real-time updates or events consumers can subscribe to?
* *Authorization Rules*: Who can access which fields or types?
* *Consumer Constraints*: Are there pagination, filtering, or rate-limiting constraints?
* *Notes / Open Questions*: Any pending decisions or integration considerations?
h3. Before this station
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h3. Ready to leave when
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h3. Other related resources
* *API Design Principles*: A concise guide to API usability, discoverability, and consistency grounded in shared design rules and real consumer needs.
* *Contract-First Capability Design*: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.
h2. 5. API Delivery
Build, test, and release APIs using modern delivery pipelines and engineering best practices.
h3. Station questions
* Use API Development Best Practices as guidance for implementing the validated contract with established frameworks and libraries, ensuring the result is reusable and maintainable.
* Build the API implementation from the validated contract using established frameworks, libraries, and team standards.
* Test APIs for functionality, security, and performance using automated testing tools.
* Use CI/CD pipelines to automate build, test, and deployment processes, ensuring consistent quality and traceability.
* Ensure APIs meet security and compliance requirements through automated checks and audits.
* Use the API Audit Checklist to ensure the API meets functional and non-functional requirements, including security, performance, and compliance.
* Deliver coding frameworks, libraries, and standards for API implementation. Implement CI/CD pipelines, quality assurance frameworks, and deployment automation tools.
* Even the best API designs fail if delivery is inconsistent. This station ensures your APIs are built with quality, tested thoroughly, and deployed reliably — enabling faster iterations and greater confidence.
h3. Before this station
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h3. Ready to leave when
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h3. Other related resources
* *API Development Best Practices*: Implementation guidance for turning a validated API interface contract into a consistent, maintainable API codebase using standard libraries, reusable patterns, and aligned development workflows.
* *API Testing Best Practices*: Guidelines for implementing automated functional, performance, and security testing throughout the API lifecycle.
* *APIOps CI/CD For APIs*: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.
* *API Security Best Practices*: A set of actionable controls for securing APIs, including authentication, authorization, encryption, rate-limiting, and pipeline-level compliance checks.
h2. 6. API Audit
Validate that APIs meet business, design, and operational standards before release.
h3. Station questions
* Conduct audits to ensure APIs meet organizational, technical, and legal standards before release.
* Use checklists, linters, and testing tools to verify consistency and conformance with standards.
* Collaborate with governance teams and domain experts to ensure APIs are ready for production.
* Establish a consistent audit process that evaluates API readiness across lifecycle stages using defined criteria, evidence, and standards. Ensure gaps are identified early and resolved before release.
* APIs are long-lived products and must meet expectations for quality, consistency, and compliance. The audit connects design decisions, implementation, and operational readiness to defined standards, reducing risk before exposure.
h3. Before this station
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h3. Ready to leave when
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
* [ ] The interface design follows agreed design standards and conventions.
* [ ] The interface contract has been validated and tested against functional and non-functional requirements.
h3. Other related resources
* *API Audit Checklist*: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.
* *API Compliance Best Practices*: Ensure APIs meet legal, regulatory, and internal compliance through documentation, controls, and automated validations.
h2. 7. API Publishing
Expose APIs securely and clearly to the right audience with the right documentation and processes.
h3. Station questions
* Publish APIs to the appropriate gateways and environments to support reusability for multiple API consumers.
* Document how consumers find and use the API, including onboarding processes and registration.
* Ensure security models, gateway configuration, and legal terms are clear and accessible to consumers.
* Enable APIs to be published to the relevant environment and have clear registration and access mechanisms (e.g., API keys, OAuth, subscription plans) depending on the API consumer segments and security and compliance requirements.
* Publishing is more than deploying — it’s about discoverability, access, and support. If APIs aren't published correctly, they won’t be used, reused, or secured effectively.
h3. Before this station
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
* [ ] The interface design follows agreed design standards and conventions.
* [ ] The interface contract has been validated and tested against functional and non-functional requirements.
h3. Ready to leave when
* [ ] The solution passes quality, security, compliance, and readiness checks.
* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
* [ ] The capability is ready to be published or released through the selected delivery mechanism.
* [ ] Consumer-facing documentation and onboarding materials are ready.
h3. Other related resources
* *APIOps CI/CD For APIs*: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.
* *API Onboarding Best Practices*: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.
* *API Audit Checklist*: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.
h2. 8. API Monitoring & Improvement
Use metrics and feedback to track API performance and drive continuous improvement.
h3. Station questions
* Monitor performance metrics (e.g., API calls, latency, error rates) and adoption metrics (e.g., NPS).
* Analyze API usage metrics and incorporate user feedback into API iterations.
* Establish a habit of reviewing metrics and planning continuous improvement activities.
* Set up analytics frameworks to track performance and engagement. Develop feedback loops, analytics tools, and engagement strategies for APIs.
* API delivery doesn’t stop at launch. Without monitoring, teams can’t improve adoption, performance, or ROI. This station ensures APIs remain useful, secure, and evolving with business needs.
h3. Before this station
* [ ] The solution passes quality, security, compliance, and readiness checks.
* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
* [ ] The capability is ready to be published or released through the selected delivery mechanism.
* [ ] Consumer-facing documentation and onboarding materials are ready.
h3. Ready to leave when
* [ ] Consumer-facing documentation and onboarding materials are ready.
* [ ] Consumer onboarding, support, and communication processes are ready.
* [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.
h3. Other related resources
* *API Metrics And Analytics*: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.
* *API Community Engagement Strategies*: A playbook for fostering API adoption by cultivating communities through content, support channels, feedback loops, and social engagement strategies.