Think of an API is a way to ask a computer system to do some work for you. You give the system something as an input, and you receive the answer as an output.
Whatever the system performed in between to get the results should not concern you per se — which is the point.

For example, when you order a coffee, you exchange money and coffee choice — the input, for the cup of coffee — the output.
You don’t focus on how the coffee was delivered from the sorting center, and which shelf it was placed in the storage room. But you do care about the quality of the result in your coffee cup.
This is how the API documentation for the coffee purchase might look like:

Notice that this simple exercise already forced us to consider a “contract” between a client and a service provider — which in this case, it’s a customer and a coffee bar. Now we clearly see the minimal requirements from a service provider to do its job (i.e. type of coffee, milk, and some money).

A product manager can build on top of this job by introducing new parameter extras:

Or maybe later, they can think of a sustainable option “in-my-own-cup,” which saves a buyer forty cents:

Notice how we moved from an abstract “buying a coffee” to a very clear set of rules: what comes in, what is returned, and what can go wrong. A product manager (PM) can now align all stakeholders around this thinking because things are clearly written. And when things are written, a juicy conversation can begin:

• For example, the supply department can review the contract and mention that they do not have oat milk but soya instead.
• The financial department can immediately ban cash payment methods and ask a PM to switch to cards only. Later, they might introduce another payment method, “punch cards,” a mini version of the coffee bar loyalty program.
• Developers can mention that “Syrop logic” is a bit shaky, so it might happen that a customer sometimes ends up with creme in their cup instead. So you, as a PM, should decide whether to wait until they fix it or remove it from the API contract.

After a healthy debate and all stakeholders are aligned — this is exactly what a product manager should strive for. And now, a team can implement the solution. The ball goes to their side of the court.

If you’re still unsure about how it all comes together, I recommend calling a meme-generating API in our hands-on course "Technology foundations for PMs".

Now that we understand the basics of the API, let’s apply it to a situation product managers often find themselves in — a search for functionality their product needs, but the one they don’t want to build themselves.
Let’s imagine you’re starting an “app for runners” and you focus customer value around useful running statistics, route building, sportswear, and health check upsells. You’d also like to integrate weather forecasts into your experience (not everyone enjoys running in the rain), but (hopefully) you’re not planning to delve into weather modeling yourself — it will take you years and maybe decades to figure out.
This is where API integration is useful: we pay a small fee, outsource the feature we need, and keep the laser focus on our core value.
So, you googled a bit and found this documentation of (paid) weather API:

What does it tell you right away? You quickly understand quite a lot after 30 seconds of reading: you can pass the city name, date/time, and get back the temperature in Celsius plus weather conditions. It also tells you that:

• Your customers will have problems in suburban locations further away from cities (because API doesn’t support plain coordinates)
• The temperature is in Celsius only (US customers will suffer unless you do something)
• It says nothing about wind (which can be not okay for runners if the wind is stronger than a certain value)

This is enough to either set a task for your team (or yourself) to integrate with this API, or continue searching and finding something else. As a leader, you performed this analysis in a few minutes without even talking to the technical specialists!
And now, the user stories for your developers can look like this:

• I would like to get a weather forecast for the next 2 hours in the location user-specified (if nothing — use geolocation): temperature, weather condition, and precipitation probability (show it on the widget — designs included)
• If this is a US customer, convert Celsius to Fahrenheit
• If the user location doesn't match any city or API, return an error, do nothing, and do not show the weather widget

If you, the product manager, decide that supporting customers outside of the big cities is a priority, you can work with the API service provider and request support for latitude/longitude for the location parameter and create a user story for your technical team to update it when it’s ready.
Similarly, if you really need wind speed support, you can either work with the same API or explore the Windy API to fetch just that. Having two underlying APIs serving the same customer feature is totally okay—in real applications, it easily can be 10 external APIs powering a small widget in the corner of the app screen (think of air quality, UV index, and so on).

With our running app, we want to introduce a killer feature — routes for runners. Yes, Google can build a route for cars and walking, but running is slightly different. So you envision the user can specify the parameters of the jogging session and get a perfect route back. What you are asking from your development team is the following API:

Notice that:

• We don’t mention how this will be achieved — via fancy machine learning (ML) or some simple ruleset. But we state what users send and what we expect back — this is a good constraint to start with.
• We moved from a fuzzy “route for runners” to a more concrete input/output contract. The tech team is already debating how to build it, where they see gaps in terms of requirements. For example, they can mention that they cannot support the preference parameter at all because map data doesn't specify details like “riverside” vs. “urban,” etc. So PMs can right away lower the bar of their dreams and remove this requirement.
• Once the API is ready, you can offer it to your app team for integration and first testing. If successful, you can start selling it to sports businesses worldwide and charge a fee for each one thousand API calls.

Understanding how APIs work in their basic from is all about being able to harness the capability to connect to other services without building everything from scratch. That’s why when you understand the design philosophy behind APIs, you’re able to set clear expectations and communicate your strategy better with your team and stakeholders.
Here’s a recap of some important things to keep in mind:

• An API consists of an input and an output, including potential errors.
• You should focus on their main product value and use APIs to outsource work for the rest.
• You should be able to google the required functionality on the internet (because most things are already built) and quickly understand the documentation.
• If you need to set requirements for other product managers or teams, you can usually express them in the API’s input/output form. This also applies if you want to offer some of your functionality via the API.
• You can also add features easily by using existing services, and open up new opportunities by offering your own APIs to others.

Want to try calling an API yourself? In reality, it's easier than it seems. Here's a link to the simulator - no registration or SMS required.

Want to pump up your technical skills in general? Come to the "Technologies for PMs" simulator, where we cover such important topics as API, architecture (Service Diagram), project complexity assessment, SLI/SLOs, and so on.