Requirements - Solution Design & Methods
-
SD06 - API First
An API First design methodology should be followed, where APIs are at the forefront of the design process, functionality and data is exposed via APIs and the needs of the API consumer have been considered.
Requirement description
This requirement is concerned with ensuring that solutions adopt an API First approach when designing and exposing functionality and data.
API First means that interfaces are designed deliberately and early in the solution lifecycle rather than being treated as a technical implementation detail. API consumers should be considered from the outset, and solutions should expose capabilities in a consistent, reusable and interoperable manner.
The objective is to improve interoperability, reuse, integration quality and consumer experience whilst reducing tightly coupled point-to-point integrations.
In simple terms:
Design APIs before building functionality, and ensure they meet the needs of the systems and users that consume them.
Scoring rubric table – SD06 API First Design
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence of API First design. APIs are absent, treated as an afterthought, or functionality is exposed only through tightly coupled interfaces. |
No API specifications. No API design evidence. No consumer analysis. No integration strategy. |
Significant service risk. Integration becomes difficult, reuse is limited, and solutions may become tightly coupled. |
| 1 | Limited use of APIs and little evidence of API First thinking. API design occurs late in delivery and consumer needs are poorly understood. |
Basic API documentation. Informal interface definitions. Undocumented integration assumptions. |
High-risk gaps. APIs may not accurately support consumer requirements and interoperability can suffer. |
| 2 | Some API First practices are evident, but application is inconsistent or incomplete. |
Partial API specifications. Some consumer requirements captured. Limited API review activity. Inconsistent interface design. |
Significant notable gaps. API quality, consistency and reuse opportunities may be reduced. |
| 3 | Much of the solution demonstrates an API First approach. APIs are documented and most significant consumers have been considered during design. |
API specifications. Consumer requirements. Architecture Decision Records. Integration documentation. API design reviews. |
Notable gaps remain. Some interfaces may have evolved after implementation, consumer needs may not be fully represented, or documentation may be incomplete. |
| 4 | Most solution capabilities are designed using API First principles. API consumers, interoperability needs and reuse opportunities are clearly considered. |
Comprehensive API specifications. Consumer journey or integration analysis. API governance review records. Consistent API design standards. Traceability between business requirements and APIs. |
Minor gaps only. Remaining deficiencies are low risk and unlikely to significantly affect integration quality. |
| 5 | Comprehensive and exemplar API First design. APIs drive architecture decisions, provide reusable capabilities and deliver a strong consumer experience. |
API-led architecture documentation. Comprehensive API catalogue. Strong consumer engagement. API governance and lifecycle management. Evidence of API reuse across services. Continuous improvement driven by consumer feedback and usage data. |
Minimal or no significant gaps. APIs are strategic assets that support interoperability, reuse and long-term architectural sustainability. |
What assessors should look for
- API First approach – Were APIs designed before or alongside implementation rather than after the solution was built?
- Consumer focus – Have API consumer requirements been identified and incorporated into the design?
- Reusable interfaces – Are APIs designed to support reuse and interoperability beyond a single use case?
- API documentation – Are specifications, contracts and integration requirements documented and maintained?
- Governance and consistency – Are APIs designed using consistent standards and subject to architecture review?
- Integration quality – Does the API approach reduce coupling and support sustainable integration patterns?
What separates a 3 from a 4 or 5
A score of 3 generally indicates that APIs are recognised as important design artefacts and most significant integrations are documented, but API design may not consistently drive solution design decisions.
A score of 4 requires clear evidence that API First principles are being applied consistently across the solution. Consumer needs, design standards and interoperability considerations should be visible in architecture artefacts and governance processes.
A score of 5 requires API First thinking to be embedded throughout architecture and delivery practices. APIs are treated as reusable organisational assets, are actively governed and demonstrate measurable value through reuse, interoperability and consumer satisfaction.
Suggested evidence examples (not SAF-mandated artefacts)
- OpenAPI / Swagger specifications
- API catalogues and developer portals
- API consumer requirements
- Architecture Decision Records (ADRs)
- Solution Design Overview (SDO) documents
- Integration architecture diagrams
- API lifecycle management artefacts
- API governance review records
- Consumer onboarding documentation
- API usage and adoption metrics
Updated: 04 September 2026 (SAF Version 1.1)