4 Levels of API Adoption
Tags: api, microservices, paas, saas
Published: 2020-11-29 10:50:38

The following is my list of non-technical patterns and common characteristics to describe degrees of adoption an engineering organisation is likely to find themselves in as part of their journey.

### Level 1: The Backend Team

![Early morning jog](https://dev-to-uploads.s3.amazonaws.com/i/os17ioht8dm8jm64l4bm.png)

- APIs built and owned strictly by backend engineers
- API design is informed mostly by the backend implementation
- Consumers create their own API client implementations using technical documentation or ask the backend engineers for support
- Written change requests used to ask for new APIs or features

### Level 2: The Full Stack

![Code Version Control](https://dev-to-uploads.s3.amazonaws.com/i/dtzzz1szmb6omukyyh9y.png)

- Engineers working on frontend features also build backend features and APIs
- API design is informed mostly by the frontend implementation
- Machine readable interfaces such as GraphQL, Swagger or Postman Collections may be used to help to consume and document the APIs
- Changes to API design are made by directly changing backend code

### Level 3: API First

![Road Trip](https://dev-to-uploads.s3.amazonaws.com/i/9d5cbn6x1xqwyheujlxn.png)

- APIs are built and owned by platform or backend engineers working together with teams delivering end to end features
- APIs are commonly designed to implement an overarching DDD (Domain Driven Design) microservices architecture
- Machine readable interfaces are published in a common API catalogue alongside documentation and are used as a design and prototyping (mocking) tool
- API designs are collaboratively reviewed and iterated on using concrete Pull Requests to modify machine readable API definitions such as GraphQL schemas or OpenAPI documents

### Level 4: Platform

![Solving problems](https://dev-to-uploads.s3.amazonaws.com/i/74j8wi6h8lsywomgziz2.png)
 
- APIs are built by engineers in multidisciplinary teams delivering end to end features built on layers of APIs
- APIs are treated as managed platform products with lifecycles and used to enable both internal and external developers
- Versioned API client packages with uniform conventions and documentation are released to make up full SDK libraries
- Machine readable API definitions act as a single source of truth for platform and data capabilities 

### Conclusion

These descriptions are by no means an exhaustive list to rank companies' API competencies but rather a tool to assess the general level of maturity using common heuristics gathered from nearly 10 years of experience in the field.

Most companies I've had a good internal view into have been somewhere between levels 1-2 with some elements of levels 3-4 already in their roadmap.

Examples of Level 4 companies are seemingly rare but in addition to the obvious big cloud players AWS, Google and Azure there's also a large group of more recent exceptional success stories with companies including [Stripe](https://stripe.com/en-de), [Adyen](https://www.adyen.com/), [Auth0](https://auth0.com/), [Datadog](https://www.datadoghq.com/) and [Twilio](https://www.twilio.com/) showing that the use of APIs to build a developer friendly platform can translate into a billion-dollar startup valuation.

At time of writing, some smaller Level 3-4 companies I'm also very excited to follow include [Netlify](https://www.netlify.com/),  [TypeForm](https://www.typeform.com/), [Vercel](https://vercel.com/), [Fauna](https://fauna.com/), [TakeShape](https://www.takeshape.io/), [Contentful](https://www.contentful.com/) and [Storyblok](https://www.storyblok.com/).

What level is your company at? Are you planning to build a level 
four API platform?

### Attribution

Illustrations: [@hrishikesh1990](https://dev.to/hrishikesh1990/i-made-100-high-quality-illustrations-totally-free-use-it-anywhere-without-attribution-452o)