API Design 'Who' - Part 1

At work I was reviewing a product team's design plan for an API heavy system. Realized that many fundamentals were missed in the design phase. My first thought was 'is there a lack of basic checklist for teams to refer'. And while browsing around, the information was indeed too distributed.

The question which will lead us to the primary design decision would be: 'Who are the consumers for this API'.

Solo, Isolated:

If the API is going to be consumed by a team and are the sole owners for it, then minimal documented API with standard versioning approaches will suffice.

Cross team, single API:

If the API is going to be referenced and maintained by other teams within the organization, it becomes necessary to publish it in a more structured manner, and keep it up to date.

Cross team, multiple API:

For companies with multiple APIs used by various teams, implementing a Developer Portal along with a Gateway is the next logical step to centralize and manage API access, and have an overview of the available APIs.

Cross team, public access, multiple API:

For organizations having entire API ecosystem, multiple API providers, and multiple API Gateways, progressing to a Unified API Marketplace is essential for streamlining management and fostering efficient collaboration.

Once the above category of consumption is decided, the tech stack, versioning support, scalability requirement will drive the other design choices. We may get to them in a follow up post.