APIs Explained for Product Managers


Make sense of REST, GET, endpoints, headers and payloads once and for all

The ‘techie one’.

As product people, we’re often referred to as the ‘techie ones’ by business, sales and marketing stakeholders. We get invited along to external meetings to go through the details of how an API integration might work, we attempt to explain (with great patience and a smile on our faces) the technical restraints to our business colleagues of a particular feature and we evangelise the impact new technologies can have on our products and our business.

Yet our engineers still sneer if we attempt to be remotely technical when tackling problems. We’re managers, not engineers, in their eyes. And rightly so; we’re not engineers and we shouldn’t try to be. Product Managers have a penchant for fancy notepads, colorful socks and user metrics. Engineers love ruby on rails, funky javascript frameworks and nutella sandwiches at 10am on a Monday morning. We’re different.

Product manager venn diagram

That leaves us in a tricky position where the business sees us as the techie people and our engineering teams think we’re ‘managers’ with no real competent skills in software development.

So what happens when you’re working on a product that is more technical than you might perhaps be comfortable with? What happens if you’re dropped into the deep end and you’re drowning in technical documentation and have no idea what any of it means?

Well, in true product management style, you’re expected to soak it up, learn on the job and get on with it.

Technology skills are part of the holy trinity of PM skills: business, technology, design and there is a strong case both for and against product managers having technical skills. My own personal view is that technical skills are an asset to product managers on the condition that the product manager’s focus remains on delivering the ‘what’ i.e. the value to the customer / business and that the ‘how’ (the technology) is viewed as the mechanism of delivering that value to the customer.

If a product manager had to survive with only 1 skillset, it would not be technical skills. I’d argue that customer empathy, strategy, business, communication and design are more important as core skills, but that technology skills can strengthen decision making, help to understand trade offs and clarify potential business opportunities when used appropriately. Getting involved too deeply into the technology results in an unhealthy focus on the ‘how’ which misses the point of product management entirely.

Introducing APIs

Of all the web technologies, APIs are seemingly more and more important to product managers as more and more products offer APIs which do cool things and open up new opportunities for customer growth and revenue.

In my experience, APIs are one of the most frequent technical concepts referenced by non-product/engineering stakeholders because of the business opportunities they present. An understanding of the fundamentals of APIs is therefore a very useful thing to have.

In this post, we’ll examine what APIs are and what the most important things to learn about APIs are as a product manager so that you can apply some of this knowledge in your daily role as a product person both in your conversations with stakeholders and your engineering team.

Why are APIs important for product managers?

The business case for APIs

APIs open up a whole world of new product and business opportunities. To get the full benefits of these opportunities businesses typically utilise APIs in 3 different ways:

  1. Integrating with third party APIs
  2. Building your own APIs for internal use
  3. Building and exposing your own APIs to your customers

As product people, I’d argue that we’re more concerned with 1 and 3 since these are where the opportunities for adding value lie. Building APIs for internal use isn’t something I’ve been heavily involved with and is something I’d normally leave to the engineering / architectural teams to decide.

1. Integrating with third party APIs

Connecting with other companies’ APIs allows you and your product to fast track adding features, functionality and tools that would otherwise take you and your team years to build. Chances are that you / your team have worked on integrating with an API at some point. Typically you’ll talk through a feature set and your engineering team will know of an API that will handle the task you need to do via a third party.

Most products today utilise integrations with APIs in one way or another. Here’s a few examples of open APIs that are widely used by millions of websites around the world today:

Braintree API

Use cases

  • Process payments for customers
  • Set up monthly recurring subscriptions for customers

Google Maps API

Use cases

  • Create a contact us pages with the location pre-determined
  • Create a transport mobile app which has metro stations on top of Google maps e.g. Citymapper (URL)

YouTube API

Use cases

  • Embed your favourite YouTube clips into your blog
  • Allow your users to search for a video on your site using the YouTube Data API

Twitter API

Use cases

  • Embed your twitter feed into your blog
  • Create a new tweet using content from your blog
  • Show a curated stream of tweets based on your hashtag (usually employed by TV channels to show users debating)

Shopify API

Use cases

  • Mark orders as fulfilled once they’ve shipped
  • Trigger email communications to customers
  • Update shipping tracking information when you get a new tracking event

These are all examples of how you can utilise integrations with third party APIs to offer new features and functionality in your products.

To dig a little deeper, let’s use Uber as an example of how multiple sets of APIs can be used in combination to create value propositions for its customers.

How Uber uses APIs

Uber uses several APIs to deliver its value, including some of the obvious ones which I’ve highlighted here:

  1. The Google Maps API to display the customer journey information and set your pickup location. The Google logo is visible on the map.
  2. The Braintree API to process customer payments.
  3. The Twiliio API to send comms to customers about their journey e.g. ‘your driver is on its way.’

Typically, products will include a mixture of internally used APIs for internal services, APIs which are exposed externally and integrations with third party APIs to offer new value to customers.

To summarise, some of the main benefits for connecting with third party APIs are:

  1. Added functionality – integrating with third parties quickly adds complex and desirable functionality to your product, almost instantaneously.
  2. Low effort – the dev effort is low for the business impact / value provided.
  3. Value over time – with many APIs new updated functionality becomes available over time as large companies mature and develop their API. A low initial up front cost for the initial integration will often pay off over time.

However, before you get carried away, it’s not all a bed of roses. There are some downsides to using third party APIs for the core of your product which need to be considered:

  1. Dependencies – if your entire product is underpinned by third party APIs you become over-reliant on external APIs which creates dependencies
  2. Risk – what happens when that funky startup you’ve been using to process your mobile payments goes bust? You go bust with it. When choosing partners with APIs to use, pick ones you think will be around in 5 years time. Nobody has a crystal ball and even larger companies can bin and modify APIs they deem to be unsuccessful but try your best to be as prudent as possible.
  3. Costs – costs increase as third parties can charge on a per request basis. Twilio charges for every single text message sent, for example. A great business model for them, not so great for you if it’s not factored into your growth models.

2. Exposing your own APIs

Should you expose your own APIs? Well, it depends entirely on what your product is / does and what your business goals are. If creating your own APIs means you’re going to get X number of new clients which means you’ll achieve your quarterly growth targets then it’s worth considering. If it’s a colleague’s pet project that demonstrates no clear business value then don’t.

For some businesses, APIs are the business; the value the company offers to customers could not exist without APIs since the value is delivered through APIs. Some examples of this include Twilio which allows companies to send text messages to customers based on user actions. Shutl is another; it leverages integrations with local couriers and local retailers to create an entirely new value proposition – same day delivery. Without the ability for merchants to connect directly into its APIs, Shutl wouldn’t have integrated clients and as such would not exist as a business.

So for some businesses, it’s a no brainer; it’s a fundamental part of your product which underpins your value proposition and you therefore need your own external APIs in order to provide the value your business exists to provide.

However, you may be in a position where you’re considering exposing your own APIs, but they are not necessarily a fundamental part of your business and are more of a tangential opportunity which may or may not work out. Your stakeholders might argue that your clients really want an API that does X,Y and Z but you’re not convinced of the opportunity.

So what do you do?

Before you decide to build expose your own APIs, ask yourself some of these questions:

  1. What is the business impact if we do create our own APIs? How much additional revenue or how many more customers are we going to get? Does having an external API get us closer to our goals? Be as specific as possible in your projections and get some data to back this up.
  2. Is your company ready for additional costs and overheads in managing the potential infrastructural complexities of an external API? Clients will need hand holding and managing and APIs that are widely used by clients will drive up your infrastructure costs.
  3. If you do build one, how will you demonstrate the impact it’s having on the business? Many execs don’t tend to understand the intricacies of APIs and you need to ensure you’re in a position to manage the exec team so that they understand what impact an externally facing API has had to your business. If it’s not likely that you’ll be able to demonstrate its value, seriously consider whether it’s worth it.

Why not run an API appetite experiment?

In true lean product fashion, one way to quickly assess the potential impact of an external API is to write up some docs / landing pages for an API before you commit to building one and drive some traffic to monitor how many potential customers sign up beforehand. You could also ask your sales team to mention the possibility of an API to enterprise clients and keep a record of the appetite to see if there’s a genuine business appetite or not.

If you do make the decision to create external APIs, get yourself a highly skilled architect and if you’re not too technical yourself consider hiring a technical product manager who specialises in API design. The technical PM won’t write code but they will have a fundamental understanding of good API design. This, coupled with an understanding of what the market wants can shape the design of your API.

If done effectively, creating external APIs can open up a world of opportunity and generate significant additional revenues. Spotify, Facebook, Google and Braintree are just some examples of companies who have benefitted tremendously from them. But it’s not just the large corporates; nifty startups in particular can see their growth trajectory explode due to opening up their APIs and evangelising them in the developer community.

One thing that puts off some product managers is that they don’t fully understand how APIs work. You may be in a position where you’re prioritizing features that you know there is an appetite for and you fully understand against a suggestion from your engineering team to develop an API which you don’t fully understand and therefore decide not to prioritise.

That’s dangerous prioritisation rationale since you’re allowing your own technical ignorance to impact potentially business critical product decisions. I mean ignorance in the nicest way possible btw; we’re all ignorant of 99% of the world’s information. 🙂

OK, now onto some of the more technical bits.

What does API mean?

API stands for Application Programming Interface. You might know that already, but does that help to describe what they do? Not really.

APIs allow two systems to communicate with each other. The best description I’ve heard is that an API is essentially a form of contract between the two systems and the API documentation determines the terms of that contract. An API is designed to a specification and in order for information to be transferred the rules of the specification must be adhered to.

To understand APIs we need a basic understanding of clients, servers and HTTP.

In this example, you can see how a basic webpage is rendered.

The client (your web browser), speaks to the server and says ‘hey, show me that picture of a dog you have’.

The server (where the files or resources are stored) says ‘sure, here it is’.

This process works is using HTTP. HTTP stands for hypertext transfer protocol and describes the transfer of information over the web.

HTTP requests are the foundation of the web. Take a look at your browser to prove it. HTTPS is a more secure version of HTTP where information is encrypted.

HTTP in the browser

Your browser makes HTTP requests to a website’s server every time a new page is loaded and it is something called HTTP methods which are used to tell the server what to do. These methods are also used by APIs. More on these later.

Once you have an understanding of HTTP and the transfer of information between a client (your browser in this case) and the server (the server which is ‘serving you the content), you have an understanding of the foundational elements of APIs.

Let’s dig a bit deeper into the specifics.

The 10 most important terms you need to know about APIs

Here’s what I believe are the most important things you need to know about APIs as a product manager. This is based on my own humble experience and not much else. Learn these concepts and you’ve got a solid foundation to speak about APIs with confidence to stakeholders and your team.

The 10 most important things to know about APIs
  1. Requests and responses
  2. REST
  3. HTTP methods
  4. Endpoints
  5. API documentation
  6. API calls
  7. Payloads
  8. Response codes
  9. Headers
  10. Authentication

There’s quite a lot to digest here and it looks a little overwhelming. So let’s take a deep breath and tackle 1 piece at a time.

1. Requests and responses

At a very basic level APIs work using ‘requests’ and ‘responses’. This video explains things v. clearly.

I request something in a specific format as outlined in the API documentation and the API responds with something in return.

For example, using the Spotify API I can request a list of songs from an album.

Spotify API for requesting an album

In order to do that, the following needs to take place:

  1. I send a request to the Spotify API
  2. As part of my request I tell Spotify which album I want to retrieve a list of songs for using an ID e.g. Spice, by the Spice Girls (a classic) has a unique ID
  3. Spotify responds with a list of songs from the Spice album in a language called ‘JSON’

The API documentation will specify what the request should be and what you can expect in the response.


REST is what you do at home with a glass of wine after a sprint planning session went badly and your engineering team want you killed before the next sprint starts.

Crude jokes aside, you’ve no doubt heard the term REST or RESTful used in several blogs and by your engineering team but you may not have any idea what it means. There are plenty of people who could spend the next 6 months talking about REST but let’s keep it as simple as possible and learn the basics.

REST stands for representational state transfer and whilst that sounds ridiculously scary it is used to describe a set of architectural principles and characteristics outlined in a document in the early 2000s by a guy called Roy Fielding. The document lays out a series of principles which should be followed in order to create a RESTful API. Thanks Roy.

Think of REST as a set of members club rules. The owner of the club is saying, ‘hey guys, look, if you want to be part of this REST club, you’re going to have to follow a certain set of rules.’ Kinda like a religion, but less scary and more rational.

What are the characteristics of a RESTful API?

The basic characteristics of a RESTful API are:

  1. Resource based– in RESTful APIs we are dealing with ‘things’ or ‘resources’. Nouns are the resources. A person, a user, a pdf, an address etc. These are all known as resources.
  2. Representations – In RESTful APIs we deal with representations of resources. If a resource is a noun, i.e. a thing, that noun can be represented in various different ways. Using API calls, the response you get back is a representation of the resource, transferred between the client and the server. Most commonly in the JSON format. JSON is a language commonly used by REST APIs. XML is another representation of the same resource.
  3. Six constraints – refers to constraints applied to RESTful architecture. In order for a service to be truly RESTful, it needs to comply with the following restraints.
    1. Uniform interface (Typically uses HTTP, resources, HTTP verbs as the actions: GET, PUT, POST, DELETE)
    2. Stateless – each request has enough information for the server to process the message.
    3. Client server – client server architecture. Always know that it’s a client / server connection, not a direct connection to the database for example.
    4. Cacheable – server responses must be cacheable
    5. Layered system
    6. Code on demand

Violating any of the principles or constraints outlines means that the service is not strictly RESTful. You can no longer class yourself as a member of the RESTful members club.

We don’t need to delve too much into these (especially since they’re a little dull) but this video goes into more depth for each of these explanations of a RESTful service if you’re interested in finding out more.

So in summary, REST is a set of principles which need to be followed in order to classify your API as a RESTful API. This uniformity makes it easier for developers to work with multiple different APIs. You don’t need to learn API specific methods; you can use REST principles for all REST APIs. Unless you’re an API product manager, that’s all you need to know. And perhaps the most important takeaway is that REST APIs all use the same HTTP Methods:

  • POST
  • GET
  • PUT

What on earth do they mean? Glad you asked.

3. HTTP Methods

When working with APIs, something called HTTP methods are used to request information. The methods are the ways you do things with APIs. Think about how you would interact with your pet as a weird, but potentially helpful analogy. You would say ‘FETCH’ if you wanted your dog to get you something, ‘SIT’ if you wanted your dog to sit and ‘PAW’ if you wanted your dog to raise its paw. The way we work with HTTP methods is similar in that they describe various ways in which you can get things done.

The most commonly used HTTP methods are: POST, GET, PUT, PATCH, DELETE.

If resources are nouns i.e. ‘things’, each of these methods is a verb which does something. HTTP methods can create, read, update and delete information (CRUD is used as an acronym).

The most commonly used methods in my experience as a product person are POST and GET, which allows you to create or read and retrieve information. GET is straightforward and is considered the safest of all the methods since it doesn’t update any information.

Here’s a summary of the most common HTTP methods:

  • Used to create new resources.
  • For example, if we wanted to create a new text message using the Twilio API, we would use the POST method since this is how you create new resources (where the resource is the text message).
  • Used to read / retrieve a representation of a resource.
  • When you perform the GET method, the response contains the information you requested.
  • GET requests are only used to read data and not change it. This means they’re considered safe.
For example, at Spotify, GET is used to retrieve a list of songs from an album. PUT
  • Used to update / replace data.
  • For example, updating a user’s email address.
  • Self explanatory. Used to delete data.

There are others but we’re only going to focus on these since these are the most common. If you know these, you know enough.

4. Endpoints

An endpoint is a place.

It’s a connection point which accepts requests to access resources on an API. An endpoint needs to be ‘exposed’ so that it can be called. Think of it as a door which can be opened or a socket in which you can plug yourself into and get what you want.

Spotify API documentation

In this API endpoint reference from the Spotify API, you can see a table which contains:

  • The HTTP method e.g. GET (which is used for reading and retrieving information)
  • The endpoint e.g. /v1/albums/{id}
  • The usage – what the endpoint is used for e.g. in this case it’s used to get an album’s tracks
  • Returns – what is returned in the response from the API
How the term ‘endpoint’ is used:
  • Hit – endpoints can be ‘hit which means we reach an endpoint to request a resource.
  • Exposed – endpoints can also be ‘exposed’ which will allow resources to be retrieved by others e.g. ‘we can expose an endpoint which will allow an image of a barcode to be retrieved’.
  • Call – ‘if we call the artists endpoint on Spotify we’ll retrieve a list of artists’.

If we look back at our Spotify example, we’ve now added further information including endpoints. Let’s understand how the endpoint is used…

Subscribe for updates

Get the latest updates in our Weekly Briefing.


Product Stacks Podcast

Product Stacks Podcast by the Department of Product. A deep dive into the tools, frameworks and processes used by product managers from top companies.


spotify api explained for product managers
Request Response
Spotify have ‘exposed’ an endpoint called ‘Albums’ which we can hit.
We hit the albums endpoint with a specific Album ID using the HTTP GET method.
This tells Spotify, ‘hey, I want to retrieve information for the album with this ID: 123’.
If we’d used the HTTP DELETE method, this would have meant we were asking to delete this album, which would have thrown an error since it’s unlikely we’d have relevant permissions from Spotify to be so destructive :).
Spotify receives our request and says
‘Hello there, I recognise that ID you sent me, it’s the Spice Girls album. Here’s the response, which contains the album information you requested. You lucky thing.’
The response from Spotify contains a bunch of information about the resource i.e. the album.
This information includes (amongst other things):
  • A link to the album art
  • A link to a preview snippet of the tracks
  • Information about where the album was released
  • The length of the track
This is known as a representation of the resource (the album). The representation will typically be in JSON format, which is a language used by APIs.

5. API Documentation

As product managers our primary concern is not with the design of APIs as such, unless you’re a technical product manager who specialises in APIs. We are mostly concerned with the functionality and business value an API can offer to our customers and the functionality of an API is typically outlined in its documentation.

For some product managers, your first foray into APIs comes when your team mentions an API and asks you to get the documentation from a third party. On first glance if you’ve not worked with APIs before documentation can be a little overwhelming as none of it makes much sense.

If you’re not familiar with API documentation, check out some examples here:

Spotify API documentation Spotify Documentation Twilio API documentation Twilio Documentation

The primary purpose of documentation is to lay down the rules of the ‘contract’ and to help your engineering team understand what functionality is available by using different API calls.

In the documentation you’ll notice a familiar set of terms, which are commonly used across all APIs. That’s one of the benefits of using the REST principles; REST APIs make use of common methods which makes it easier to integrate into multiple APIs.

API documentation will typically include many of the following:

  • Authentication instructions – how you connect with the API
  • API endpoints – what endpoints are available
  • Resources – what resources are available for you to access. For example in the Spotify API, they allow to you access Playlists, Albums, Artists, Songs
  • Request format – how an HTTP request to the API should be formatted
  • Response format – how an HTTP response is formatted when you receive the response
  • Response codes – what response codes are included in the response (we’ll talk about these later).

6. API calls

We refer to the requests to APIs as API calls. Not telephone calls but exchanges of information.

API calls involve hitting an endpoint with the expectation that the API will respond with the information you need.

In the Spotify example, you call the albums endpoint with a specific album ID and Spotify responds with information about that album.

7. Payloads

You’ll sometimes hear engineers refer to the ‘payload’. This is a fancy way of talking about the response from an API.

It refers specifically to the meaningful information in a given set of data. Not everything in an APIs response is something we care about, so the term payload is used to distinguish between the stuff we’re interested in and the stuff we’re not.

E.g. ‘If you check the payload from the Spotify API you can see the length of the track is 3 minutes’

8. Response codes

Every time you get a response from an API, it comes with its own response code, which is simply a number with a meaning attached to it.

Some useful response codes to know

HTTP response code Meaning
200 Success. Everything’s fine.
301 The resource you’re looking for has been moved permanently.
400 There’s a problem on the client side. The most famous error code is the 404 error. It means the server can’t map the request to a resource.
500 There’s a problem on the server side.

There are plenty of others so this list is by no means exhaustive but it’s enough to give you a foundational knowledge of the most frequent so that when people talk about ‘a 500’ you’ll know it’s a problem with the server.

9. Headers

When you send a request to an API, your request will include something called headers. The response from an API will also contain headers.

Headers are additional useful bits of information which are sent and received along with your HTTP methods. Some headers are mandatory and some are very rarely used.

Some of the most common headers are:

  • Authorisation – the authorization / authentication credentials such as username and password
  • Content-type – this determines how the information is presented back to you and what content is used. JSON is the language typically used by APIs.
  • Date – represents the time and date of a request or a response.

This is an example of some headers that are sent with an API request on the Spotify API.

Spotify API with headers

10. Authentication

In order to interact with an API and in order to establish your connection with the API, you need to tell the API that you’re not just some random idiot and that you’re a genuine, bona fide user who has the necessary privileges to access the API. In order to do this, you need to access APIs using an authentication token.

In the same way as you would authenticate yourself when logging into your email or Facebook account using a username and password, you need to do something similar for accessing APIs.

If you have an external facing API which needs to be accessed by clients, they will typically be issued with a security token and credentials which they will need to use to access your API.

There’s a subtle, but important distinction between authentication and authorisation.

  • Authentication – proves who you are
  • Authorisation – defines the what you are permitted, or authorised to do

Authentication usually includes:

  1. Username
  2. Password
  3. Access token

If you have a product with an external API, your third parties will be given a username, password and access token to access your API. Often, a token can be provided in the sandbox environment to allow their developers to play with.


OAuth is an authorisation framework that can also be used to authenticate and authorise users. Using OAuth involves a separate authentication server which authenticates the user and then passes them back to the resource API.

Bringing it all together

So that’s enough theory, the best way to learn these things is to play with them yourself.

For this example, we’re going to use the Spotify API to demonstrate the different HTTP methods in action. Ready? Let’s go.

Example 1 – POST
POST example using Spotify API
Using the HTTP POST method, we’ll add tracks to a playlist.
POST /v1/users/dickford/playlists/3uv6e2SoCMhnWN1PTvYZTP/tracks?position=1&uris=spotify%3Atrack%3A3m6KkYKdnbffMpGd9Pm9FP HTTP/1.1 Host: api.spotify.com Content-Length: 0 Accept-Encoding: gzip, deflate, compress Accept: application/json User-Agent: Spotify API Console v0.1 Content-Type: application/json Authorization: Bearer XXX
HTTP/1.1 201 Created Access-Control-Allow-Headers: Accept, Authorization, Origin, Content-Type Access-Control-Max-Age: 604800 X-Content-Type-Options: nosniff Content-Encoding: gzip Transfer-Encoding: chunked Access-Control-Allow-Credentials: true Strict-Transport-Security: max-age=31536000; Keep-Alive: timeout=600 Server: nginx Connection: keep-alive Cache-Control: private, max-age=0 Date: Wed, 21 Dec 2016 12:36:48 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE Content-Type: application/json; charset=utf-8 { "snapshot_id" : "hHeb6EFItvhUyJdZFZGioPNR3dyDifnyZKNY/ItP5JeS0+uPdLkZYu+Gj8T9NwyA" }
Example 2 – GET
GET example using Spotify API
Using the HTTP GET method, we’ll get an album.
GET /v1/albums/3x2jF7blR6bFHtk4MccsyJ HTTP/1.1 Host: api.spotify.com Accept: application/json Content-Type: application/json Accept-Encoding: gzip, deflate, compress Authorization: Bearer XXX User-Agent: Spotify API Console v0.1
HTTP/1.1 200 OK Access-Control-Allow-Headers: Accept, Authorization, Origin, Content-Type Access-Control-Max-Age: 604800 X-Content-Type-Options: nosniff Content-Encoding: gzip Transfer-Encoding: chunked Access-Control-Allow-Credentials: true Strict-Transport-Security: max-age=31536000; Keep-Alive: timeout=600 Server: nginx Connection: keep-alive Cache-Control: public, max-age=7200 Date: Wed, 21 Dec 2016 12:42:23 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE Content-Type: application/json; charset=utf-8 { "album_type" : "album", "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "copyrights" : [ { "text" : "(C) 1996 Virgin Records LtdThis label copy information is the subject of copyright protection. All rights reserved.(C) 1996 Virgin Records Ltd", "type" : "C" }, { "text" : "(P) 1996 The copyright in this sound recording is owned by Virgin Records Ltd", "type" : "P" } ], "external_ids" : { "upc" : "00724384217457" }, "external_urls" : { "spotify" : "https://open.spotify.com/album/3x2jF7blR6bFHtk4MccsyJ" }, "genres" : [ ], "href" : "https://api.spotify.com/v1/albums/3x2jF7blR6bFHtk4MccsyJ", "id" : "3x2jF7blR6bFHtk4MccsyJ", "images" : [ { "height" : 640, "url" : "https://i.scdn.co/image/f9dac1591869800af56100db4d69f28998cf1f06", "width" : 640 }, { "height" : 300, "url" : "https://i.scdn.co/image/dc265db757daf10739890ead6ee1c88415c3bf33", "width" : 300 }, { "height" : 64, "url" : "https://i.scdn.co/image/0433314818206d69e9aa18e91a6abe98eb6403ba", "width" : 64 } ], "label" : "Virgin Records", "name" : "Spice", "popularity" : 73, "release_date" : "1996-11-04", "release_date_precision" : "day", "tracks" : { "href" : "https://api.spotify.com/v1/albums/3x2jF7blR6bFHtk4MccsyJ/tracks?offset=0&limit=50", "items" : [ { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 173026, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/1Je1IMUlBXcx1Fz0WE7oPT" }, "href" : "https://api.spotify.com/v1/tracks/1Je1IMUlBXcx1Fz0WE7oPT", "id" : "1Je1IMUlBXcx1Fz0WE7oPT", "name" : "Wannabe - Radio Edit", "preview_url" : "https://p.scdn.co/mp3-preview/27cda6c08b6ddeddd4d3116aef7769ea3b2b11f5?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 1, "type" : "track", "uri" : "spotify:track:1Je1IMUlBXcx1Fz0WE7oPT" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 235973, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/1yTQ39my3MoNROlFw3RDNy" }, "href" : "https://api.spotify.com/v1/tracks/1yTQ39my3MoNROlFw3RDNy", "id" : "1yTQ39my3MoNROlFw3RDNy", "name" : "Say You'll Be There - Single Mix", "preview_url" : "https://p.scdn.co/mp3-preview/284ced5dc4ecbd6d8d10820fe243fcb844984e1b?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 2, "type" : "track", "uri" : "spotify:track:1yTQ39my3MoNROlFw3RDNy" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 241026, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/36AWdhZIGLUTkWpJDhe7va" }, "href" : "https://api.spotify.com/v1/tracks/36AWdhZIGLUTkWpJDhe7va", "id" : "36AWdhZIGLUTkWpJDhe7va", "name" : "2 Become 1", "preview_url" : "https://p.scdn.co/mp3-preview/0ada38f0ba8805acc54ac856ad1a321fb5c553d8?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 3, "type" : "track", "uri" : "spotify:track:36AWdhZIGLUTkWpJDhe7va" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 218573, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/61PwiYyJhF1HLi0OXomzQE" }, "href" : "https://api.spotify.com/v1/tracks/61PwiYyJhF1HLi0OXomzQE", "id" : "61PwiYyJhF1HLi0OXomzQE", "name" : "Love Thing", "preview_url" : "https://p.scdn.co/mp3-preview/5001f6855da227428cf4f9f11e199f748abbc58a?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 4, "type" : "track", "uri" : "spotify:track:61PwiYyJhF1HLi0OXomzQE" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 251533, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/5SAGopoaraFmLS08bNjLxB" }, "href" : "https://api.spotify.com/v1/tracks/5SAGopoaraFmLS08bNjLxB", "id" : "5SAGopoaraFmLS08bNjLxB", "name" : "Last Time Lover", "preview_url" : "https://p.scdn.co/mp3-preview/c56dcd79ed5dd79647fee35c11f203a563c5f1b8?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 5, "type" : "track", "uri" : "spotify:track:5SAGopoaraFmLS08bNjLxB" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 304960, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/3dNv3OuX6ol9si6PZ9KSAh" }, "href" : "https://api.spotify.com/v1/tracks/3dNv3OuX6ol9si6PZ9KSAh", "id" : "3dNv3OuX6ol9si6PZ9KSAh", "name" : "Mama", "preview_url" : "https://p.scdn.co/mp3-preview/5ee0473def778932e997becc6f706df2fdbb0385?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 6, "type" : "track", "uri" : "spotify:track:3dNv3OuX6ol9si6PZ9KSAh" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 240706, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/1jI1aLmm5HTwiMtvsbwDJw" }, "href" : "https://api.spotify.com/v1/tracks/1jI1aLmm5HTwiMtvsbwDJw", "id" : "1jI1aLmm5HTwiMtvsbwDJw", "name" : "Who Do You Think You Are", "preview_url" : "https://p.scdn.co/mp3-preview/62c225d25d4485f074bffeba580d3071ac960ab7?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 7, "type" : "track", "uri" : "spotify:track:1jI1aLmm5HTwiMtvsbwDJw" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 245026, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/6qL8tweXFMqztcMwNB4r7y" }, "href" : "https://api.spotify.com/v1/tracks/6qL8tweXFMqztcMwNB4r7y", "id" : "6qL8tweXFMqztcMwNB4r7y", "name" : "Something Kinda Funny", "preview_url" : "https://p.scdn.co/mp3-preview/4497abc4ebc45a4a0bfb02d9b5c282194123d412?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 8, "type" : "track", "uri" : "spotify:track:6qL8tweXFMqztcMwNB4r7y" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 265640, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/2QMa85sq03n0NhDAjQe5eQ" }, "href" : "https://api.spotify.com/v1/tracks/2QMa85sq03n0NhDAjQe5eQ", "id" : "2QMa85sq03n0NhDAjQe5eQ", "name" : "Naked", "preview_url" : "https://p.scdn.co/mp3-preview/d0039c099350be18c4156e82c7c487412006d0a0?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 9, "type" : "track", "uri" : "spotify:track:2QMa85sq03n0NhDAjQe5eQ" }, { "artists" : [ { "external_urls" : { "spotify" : "https://open.spotify.com/artist/0uq5PttqEjj3IH1bzwcrXF" }, "href" : "https://api.spotify.com/v1/artists/0uq5PttqEjj3IH1bzwcrXF", "id" : "0uq5PttqEjj3IH1bzwcrXF", "name" : "Spice Girls", "type" : "artist", "uri" : "spotify:artist:0uq5PttqEjj3IH1bzwcrXF" } ], "available_markets" : [ "AD", "AR", "AT", "AU", "BE", "BG", "BO", "BR", "CA", "CH", "CL", "CO", "CR", "CY", "CZ", "DE", "DK", "DO", "EC", "EE", "ES", "FI", "FR", "GB", "GR", "GT", "HK", "HN", "HU", "ID", "IE", "IS", "IT", "JP", "LI", "LT", "LU", "LV", "MC", "MT", "MX", "MY", "NI", "NL", "NO", "NZ", "PA", "PE", "PH", "PL", "PT", "PY", "SE", "SG", "SK", "SV", "TR", "TW", "US", "UY" ], "disc_number" : 1, "duration_ms" : 228533, "explicit" : false, "external_urls" : { "spotify" : "https://open.spotify.com/track/6bh25NILjNfJnIvGRT2emC" }, "href" : "https://api.spotify.com/v1/tracks/6bh25NILjNfJnIvGRT2emC", "id" : "6bh25NILjNfJnIvGRT2emC", "name" : "If U Can't Dance", "preview_url" : "https://p.scdn.co/mp3-preview/108037c5aaa88461fa097561132f755ee382eae7?cid=8897482848704f2a8f8d7c79726a70d4", "track_number" : 10, "type" : "track", "uri" : "spotify:track:6bh25NILjNfJnIvGRT2emC" } ], "limit" : 50, "next" : null, "offset" : 0, "previous" : null, "total" : 10 }, "type" : "album", "uri" : "spotify:album:3x2jF7blR6bFHtk4MccsyJ" }
Example 3 – PUT
PUT API example using Spotify
Using the HTTP PUT method, we’ll follow a playlist.
PUT /v1/users/spotify/playlists/3lPrXjj2EgTj9XeamIbObF/followers HTTP/1.1 Host: api.spotify.com Content-Length: 17 Accept-Encoding: gzip, deflate, compress Accept: application/json User-Agent: Spotify API Console v0.1 Content-Type: application/json Authorization: Bearer XXX {"public": false}
HTTP/1.1 200 OK Content-Length: 0 Access-Control-Allow-Headers: Accept, Authorization, Origin, Content-Type X-Content-Type-Options: nosniff Access-Control-Max-Age: 604800 Access-Control-Allow-Credentials: true Strict-Transport-Security: max-age=31536000; Keep-Alive: timeout=600 Server: nginx Connection: keep-alive Cache-Control: private, max-age=0 Date: Wed, 21 Dec 2016 12:49:49 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE
Example 4 – DELETE
API DELETE example using Spotify
Using the HTTP DELETE method in the Spotify API, we’ll unfollow a playlist.
DELETE /v1/users/spotify/playlists/3lPrXjj2EgTj9XeamIbObF/followers HTTP/1.1 Host: api.spotify.com Content-Length: 0 Accept-Encoding: gzip, deflate, compress Accept: application/json User-Agent: Spotify API Console v0.1 Content-Type: application/json Authorization: Bearer BQDa84HaEv-l-NOa8mxbton9XgOpAN4PpXlRXab1tEZOpiJ5OPOBi_58EluWuUK-9h9Se0kGjIUwiH-_zV7IbvrTRn5Bw8QKgjv3L8XwHFO1kp8R3XAHbrCX0BupSav8zPiPuYvX3nFbXmdQOcBUOnIP0-XyZjm3j_Av497Txz30SS56K7wWZXqa9vEz_Fekr9TAW-rsCjAJ4rJr3he_3fj44ERemaWIFCtU
HTTP/1.1 200 OK Content-Length: 0 Access-Control-Allow-Headers: Accept, Authorization, Origin, Content-Type X-Content-Type-Options: nosniff Access-Control-Max-Age: 604800 Access-Control-Allow-Credentials: true Strict-Transport-Security: max-age=31536000; Keep-Alive: timeout=600 Server: nginx Connection: keep-alive Cache-Control: private, max-age=0 Date: Wed, 21 Dec 2016 12:52:46 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE

So how does all this help you in your role?

We’ve covered quite a lot there! But how can you apply all this in your role as a product manager?

Well, here are some things to consider, now that you know more about APIs than you did before:

  • Opportunities – what are the opportunities for you and your product? How can APIs help you to achieve your goals? Is it worth running any ‘API appetite experiments’ to discover if a market for your APIs exists?
  • API Audit – what APIs are currently being maintained but are not used? Can you bin any that are taking up development / maintenance effort?
  • Confidence – can you now speak more fluidly about APIs with your engineering teams and your stakeholders about the opportunities and downsides to APIs? You can be more confident to prioritise API related features since you now have a basic knowledge of how they work and what the benefits might be for your product.

Congratulations. You’ve officially mastered the most useful things to know about APIs as a product manager. Now go and grab yourself a nutella sandwich.

Useful tools

Here are some useful API related tools for product managers:

  • Apigee, a nice tool for APIs
  • PAW, a great tool for use on the Mac
  • Rested.io, a nifty website to enter API requests. Useful for accepting API related user stories.

Useful videos

Download your template

Enter your email below to get access to the product roadmap templates.

Check your email to access your resource

Download your template

Enter your email below to get access to the product roadmap templates.

Check your email to access your resource

Department of Product Email Optin Roadmap

Reinvent your roadmap

Communicate your roadmap clearly and beautifully. Subscribe to download your free template today.

Check your email to access your resource

Download your template

Enter your email below to get access to the product development models.

Check your email to access your resource

Download your template

Enter your email below to get access to the product development models.

Check your email to access your resource

Share This