When people talk about an API design methodology, sometimes they mean an API design approach, such as contract-first, code-first or prototype-first. Or they mean API design best practices, such as “Implement data pagination and filtering” or “Resource URI naming conventions”. While API design approaches and API design best practices are involved in an API design methodology, they are not by themselves, an API design methodology. 

An API design methodology as a detailed guide to the process of designing an API, from requirements gathering to final machine-readable API description files. It involves translating business requirements into a definition of API resources, methods, and interaction sequences. 

An API design methodology is supported by a particular API design-approach (as I have listed above), API standards defined in an API style guide, and software and AI tools (that help analyse requirements and generate definitions and documentation), as shown in the figure below. But the process is distinct and has clear process gates/phases.  

In these series, I will be talking about five API design methodologies created by practitioners. They are (in no particular order):

In this series, I will map out the features they have in common, where they differ, and what organisational context I think each of them best fits. After analysing these five methods, I’ll look at one organisation who have published their API design methodology publicly, and also analyse who it sits against these five.

In two words: consistency (which means a better developer experience for the API consumer) and efficiency (which means reduced costs for the API producer). Let’s look at these in turn.

Following a good API design methodology ensures that API designers:

Combined, this means less rework and more time saved.

A good API design methodology means that the engineering team have a repeatable way of producing APIs that are consistent, and so provide great developer experience (DX) and agentic experience (AX) for consumers. Mike Amundsen puts this best:

Establishing an API design methodology may be overkill for solo developers or a very small team developing trivial services. But when a large number of teams (10+) are building a business capability platform [1] - that is, platforms that expose functions from the business domain - then the ability to provide a consistent way of doing this becomes important.  The question arises how do you scale good API design? Or even more generally, how do you scale good API delivery?

I created the  Ikenna® Governance Toolkit for APIs (IGT), as a set of thinking tools for creating and improving the API delivery operating model for large-scale API programs. An API delivery operating model (ADOM) visualises the people, capabilities, value delivery chain, technology, and scorecards required to operationalise and govern the implementation of an enterprise API strategy. An ADOM that helps Engineering Directors, Heads of Platform Engineering and Heads of Architecture see on one page, the essential components that support the governance and safe, consistent delivery of their APIs. It also helps them see gaps in governance and what they need to deliver APIs. 

Using a set of questions I discuss with teams in a workshop and other evidence I gather (API description files, process documentation, and so on), I assess the API Design Capability Score of the organisation. Here are some of the Likert-style questions I ask, with answers provided on a 5-point Likert scale:

The computed scores are represented in the following table:

I work with clients to understand what the score means for them and how to improve this score based on their improvement goals. However, I have a lot of experience with core-banking platform APIs and they are my focus. It is a rich domain where a clear API design methodology is essential.

Having discussed how API design methodologies fit in the larger picture of API delivery operating models, let me discuss the first API design method on my list. In the next issue, I’ll discuss Annegret Junker's and Fabrizio Lazzaretti’s Synergistic Blueprint API Design process.

Workflows as Abstractions to Capabilities: Bruno Pedro explores the evolution of API design from individual endpoints to higher-order workflows that encapsulate business capabilities.

Unified.to Alternatives: A Technical Overview for 2026: Kateryna Poryvay discusses the evolving landscape of API integration, specifically addressing the merits and drawbacks of "Unified APIs" versus alternative integration strategies.

Goodbye Java, Hello Go!: Sanjiva Weerawarana and Sameera Jayasoma of WSO2 detail their strategic transition from Java to Go (Golang) for developing high-performance middleware and cloud-native components. The authors explain that the move was driven by the need for faster startup times, lower memory footprints, and superior concurrency management, which are essential for modern containerised and serverless environments.

The Enterprise API Strategy Cookbook: 8 Ingredients for Legacy Modernisation: Steve Roberts outlines a comprehensive framework for using APIs as the primary vehicle for modernising legacy enterprise systems without disrupting core business operations. His strategy allows for a phased migration to the cloud and microservices, ensuring that legacy constraints do not stifle the pace of contemporary innovation.

2026: The Year APIs and AI Become Non-Negotiable for Financial Services: Laura Heritage argues that the convergence of APIs and Artificial Intelligence will move from being a competitive advantage to a fundamental survival requirement for the financial services sector.

Tracing Bullets for API Prototyping in the Age of AI: Enjoy conversations between API Change Blog’s Bruno Pedro and Irina Kamalova, VP of Lead Software Engineering at JPMorgan Chase, she shares interesting ideas around API prototyping and AI-related software development.

Legacy Modernisation and APIs: Pathways to Agentic AI Success: Alex Pan contends that for AI agents to be effective in an enterprise context, they must have seamless access to historical data trapped in legacy systems, which can only be unlocked via a robust API strategy.

KubeCon + CloudNativeCon: The Cloud Native Computing Foundation’s flagship conference. Amsterdam, Netherlands from 23-26 March, 2026.

Apidays New York: Location: Convene 360 Madison, New York, Date: 13 - 14 May 2026

API Conference London 2026: The Conference for Web APIs, API Design and Management Date: May 11 – 15, 2026, Location: Park Plaza Victoria London, UK.

Nordic APIs Platform Summit 2026: October 12 – 14, 2026, Location: Stockholm, Sweden