welcome everyone to this live session on API product strategy. Thanks very much for joining, and my name is Richard. I'm from the Department of Product. And today we are joined by Abhishek, the lead PM at Square, who will lead today's session. So welcome everyone and welcome to Abhishek as well. Um, we're going to be covering a lot of things to do with APIs today. So we're going to be looking at API terminology, some of the essential terms that you need to know as a product person, how to develop an API strategy, and how to monetize your APIs. I would also share some useful tools as well. So we expect today's session to last around 30 to 35 minutes. And if you have any comments or questions, then feel free to use the chat tool on Zoom. And then, um, at the end, we'll come to those questions. At the end, and if we don't have any time for some of those questions, then we'll email you directly afterwards as well. So please feel free to use the chat tool to ping any

comments or feedback or questions that you might have as we go, but we'll come to those questions at the end, at the end of today. Um, and so another bit of housekeeping as well, the session is being recorded. So, if you do need to shoot off for any reason, then no worries. Uh, the recording will be sent around directly to all the registered participants as well. Um, so yeah. So before, before we kick off, just want to have a, a big shout out to our partners at Senberg as well. So today's session is brought to you by our partners at Senbert, and Senberg believes that conversations are at the heart of building relationships and getting things done. So they have built the world's most proven conversations platform for mobile apps, of course, chat, voice, and video. And Sendbird has helped over 1,200 businesses worldwide to improve customer retention, conversion, and support with their in-app conversations platform. Industry leaders like Reddit, DoorDash, and Hinge all use Sendbird to drive increased transactions and loyalty for hundreds of millions of users every month and for

more information you can go to sendbird.com. So with that, I'm going to hand over to Abhishek who is going to lead us through today's session. So over to you, Abhishek. Thank you, Richard. Hey, everyone. I'm Abhishek. I'm a product lead at Square. Throughout my career at my previous company, PayPal, and at Square, I've integrated with several third-party APIs, and I've launched a few APIs and monetized them successfully as well. During today's session, we would walk through API product strategy, and I would love to share a few stories from my own personal experience. All right. Before we dive into API, let's just talk about a few basic API terminologies that will help level set the field. All right. API stands for application programming interface, and when we talk about interface here, it basically means the API allows two systems to talk to each other. A good real-life analogy can be thought as you're going to a restaurant. You're in the restaurant and you want to order something from the kitchen. You talk to the waiter, and the waiter

basically, is the interface between you and the kitchen, and you have an API documentation, which is the menu card. Using the menu card, which serves as a repair documentation, you know exactly what items does this business offers, what is the price of each item, and you can make an informed decision and tell your waiter to bring that specific item. So wait till now is interface between you and the kitchen, which can be taught as a backend server. You send your request, and then you get a response, your item, your food back from the kitchen. Let's type a little bit deeper into the words. I talk about request and response. This is one thing that you'll see a lot in API documentation. You will see developers talking about request and response, and they form the core aspects of API product strategy as well. See, there's a client that says, Can I have a picture of a dog, please? This whole thing, the whole demand, is basically termed as a request. It can be as simple as asking for one thing. It can be asking multiple things. But whenever a system, a client, makes any request to the server.

that whole thing is called as a request. Now, the answer that you get back from the server, that's called the response, which in our case would be okay, here it is. You would get a success message and you get back a picture for talk. Any interaction between two systems, especially a client and a server, can be thought of as a request and response. When a client requests something to the server, the server acknowledges that request, processes that request, and gives backs a response. When you look at any API documentation, which you would see in this session further, you would see what would be a sample request, what would be a sample response, so that your developers can integrate with that API, correct? And while building your own API as a PA, you would sometimes have a very strong say in determining, hey, this is how a request should be structured, this is the nomenclature, this is how the response should be structured, etc. Let's talk about one more key terminology that is used in API, which is called endpoints. So, an endpoint is basically the place where the API makes a request where all the

representation of resources sit and where you get back the answer from. Let's take the example of a Spotify API. I just want to get back all the albums in my profile, so I will call the album's endpoint with a request that hey, give me a list of my albums. The endpoint albums would know how to interpret the requests, and the client would process the request and send back a response saying here is a list of all the albums in your profile in a format, which can be a JSON format if you're talking about REST APIs. But the area, the URL where we made a hit to get back the albums, that is basically called the endpoint. And when you hear the terminology endpoint, you would hear a few other words associated with this, such as hitting the endpoint, or calling the endpoint, or hey, we have exposed this endpoint, and now this endpoint is public. These are all terms used in collaboration in conjunction with the endpoint. So you have a URL, you have an area where all the resources sit, you basically hit that endpoint, and you get back all the

answers from there. Let's just take a real-life example. I'm using a client called Postman. It is one of the tools that helps developers test APIs in production or in a staging environment or in a sandbox environment. What I'm doing right now is I'm calling the API, and what I want to do is get air quality data in the UK. I'm hitting the endpoint slash air quality. I'm calling this API, I'm making a GET call. There's no other parameters, there's nothing else in my request. All I'm saying is, Hey, I'm hitting the endpoint, get me all the data that I have, and let me click on send. My request goes, and what I have here now is called the response. So, my response will have certain fields. It will tell me what's the ID, what's the type, it'll tell me the current forecast, it will tell me what's the publish date, from date, etc. Now, this by itself may mean a lot, and you may not interpret what all this is, but if you go back to this site and

look at API documentation. A good API documentation will tell you the meaning of each and every field, how it is structured, what does it mean. So now your developers, and you as a product person, can understand it, integrate it within your system, and can do anything. Maybe I'm building a website that just shows me what's the local air quality. I may recommend you certain products based on that, and I can just hit this API, get all the data back, and show it in a more visual or more appealing format. The possibilities with an API are endless. Talking about the documentation, I just want to show quickly, uh, Send by documentation as one of the examples of how API should be documented. We looked at the request that we sent to the air quality server, we looked at the response that we got, and we saw a bunch of fields there. In the real world, when you build out an API, you actually build out a very dedicated documentation for the API. What does the request body contain? What is the type of the property that you're sending? And what is

a description. What does it actually mean? And so, this is how Set Bed has documented, and it's a good example of documentation. But each and every field was really, really well-documented. And then you decide what's your, and then they have just given a request body example. This is how a sample request would look like. In the previous example I showed you, there was no body to the request. It was just hitting a URL because we did not have any customization to the request. But in this case, maybe I want to have a customization. I want to have an announcement group. I want to decide certain messages, etc. What is the time when I'm trying to schedule my message, etc.? And then this is what a sample response to the server look like. So, I now know when integrating with SendBird's API that, hey, this is what a sample response would look like. And if this is a response, these are some of these certain actions that I would be taking in, uh, on the application that I'm building. A sample request and a sample response.

these are the core principles of writing a good API documentation. All right, now having gone through some of the basics of API, let's just look at one more key term over here. One of the key terminologies in API that we hear a lot nowadays is GraphQL. And we talk about REST API. So let's just dive a little bit deeper into what is REST versus GraphQL. So what we saw right now was an example of the REST API. The REST is an architectural style that's standard for developing APIs, and it's today, it's one of the most popular formats of defining an API. So basically what you do is you define certain endpoints, you define a request format, which we saw in Send Word's documentation, you define a response format. Whenever you hit an endpoint, you have to have a request that's supported by that endpoint, and it will always get a response back, which is very similar to what you have in your documentation, what is defined for that endpoint. Say for example, if I want to use Instagram's API and I want to get my

followers. I will just enter endpoint followers and get a list of all the followers that I have. If I want to get a list of all the posts, I would hit an endpoint called post and get a list of all posts. If I want to get a list of all the likes that I have received on the post, I would just probably hit an endpoint called likes and get all the different likes that I've received. So you see the whole Genesis architect on a way where you have several different endpoints, and then you have a request format and a response format, and you get a specific response to a specific request from a very specific headboard. Now, GraphQL, on the other hand, is very different. It's a query-based language, so in your request, you would actually write a query to tell what are the different responses that you would need. So within a single request, I can write a query that says I want to have first 100 users, first 50 followers, and first 50 likes, etc. If using the same endpoint within the same query, I will be able to get all the

data from graphql that's basically the power of crop ql. Now, basically where the advantage and disadvantage lies basically in rest and time can be inefficient. You may suffer for something called under resource or over resource. Maybe I want only certain parts of a response, but I can't customize my response. Whatever response the server gets gives, I'll have to take that. And that basically means getting all that data passing through the data. Whereas in graphql, it's highly optimized. You can exactly choose what response you would need and how you would need that. And that's basically what graphql can give you. So, in short, the rest is an architectural style that's highly dependent on endpoints. You have a specific endpoint for a specific use case. You have a specific request format and response format for that endpoint. Whereas graphql, on the other hand, is a query language that allows you to customize and call specific responses that you would need from that server. Now, having covered the basics of apis, this is just a brief primer. You know, API is a broad topic, and there are

definitely great resources online to dive deeper into the more technical aspects of your API. But for the majority of the session, what we would cover today is your API product strategy. As a product manager, how can you strategize and build your product roadmap and your strategy around API? So when integrating with APIs, there are two core approaches. Number one is you integrate with a third-party API or a different API. Of course, you can also connect with APIs within your own company. Say maybe your company's risk department gives out a risk API that tells you how risky this user is, and you can deny or approve that transaction. So you're definitely calling a third-party API, but in this case, a third party is your internal org within your own organization. The second core approach is where you build your own API, you productize it, and you monetize it. Now, what are the advantages or why should I basically be integrating with a third-party API? So a good way is you add new value really quickly and you have low effort versus report for

example: If I'm building a startup that just basically matches dog workers in my area, I have pet doors, and I need someone who can walk my talk. Maybe I want to build out a map view to show the different people in my locality, University. Maybe I want to allow a functionality that will allow people to book somebody on the platform and make a payment on the platform. Now, if I build out a product roadmap, I would quickly figure out that okay, I need a capability to show map within my app. I need a capability to accept payments within my app. Now, we can build all those capabilities ourselves, but it takes us years to build those capabilities. A quicker way would be maybe I connect with Google Maps API to show the map rendering. Maybe I connect with PayPal or Stripe or Square API to accept payment, rather than building out a payment Gateway on my own. Maybe I used Twilio API to send out SMS confirmation when a booking is complete, rather than building out my own SMS architecture or service. So, this way I'll be able to launch my

product really really quick. There will be low effort from my site, but the reward will be really great. I'll be able to build out an NDP, test it in the market with very low effort from my side. So that's basically the core idea why you would want to integrate with third-party APIs and look at your product roadmap, look at your product strategy, and figure out if there are ways you can optimize your growth by using keyword particle APIs. The other part is where I have built out certain functionalities myself and I just want to productize and monetize them on my own because I built out my own app of dog walkers. Now I have a database of all the peoples who are willing to work their own talks. Maybe I can just publish it as an API to developers who can build applications on top of it. You hit my endpoint with your latitudinal longitude and I can tell you how many dog walkers are there within 30 mile radius or 20 mile radius. I can build that API. Maybe I do market research and figure out okay there is a

definite need for this API in the market, and people are ready to pay for it. But before we dive into productizing and monetizing your own API, let's cover the first part in detail, which is integrating with third-party API. Now, uh, APIs are cool. Everyone may want to love with it, want to integrate with them, but your core product principle of Life first. You first have to figure out is there actually a need for a third-party API to be integrated. So look into your product strategy, look into your all your company strategy, and figure out what are some of your roadmap themes. Maybe in the current deliverables near term or future. Examples here are maybe you want to build out customer service support capability. And then you would have to show dashboard, you have to show reporting and analytics, all the raw call data that comes in. Maybe you want to parse it, maybe you want to do semantic analysis on them, and figure out hey, whether most of our calls are happy, sad, neutral, or how bad they are. So you figure out certain themes in your

roadmap. Where hey, these are the functionalities you would want to do it. You would look at the opportunity sizing that hey, if I build out these features, will this help my company or not? Will this help my product strategy or not? And you figure out yes, there is definitely a possibility for that. That's when you start looking out for third-party Partners who can provide that capability. Look at them, figure out what value they are providing, and whether that aligns with your product strategy and Company strategy or not. So the first step to integrate with third-party API is actually to figure out an internal need into your own product roadmap, into your own product strategy, and then figuring out those parties. Now as a PM, you would first figure out the demand, you would do a market research, you would figure out who are the different providers in that area. You can also partner with your business development team in your organization and figure those out. But once you have zeroed on a couple of providers out there, there's a very important step that you would need to do, which is the API.

Health assessment and don't try to do it alone. Bring your developers on board soon. Under cycle and take the help to figure out the technical challenges to the APIs as well. The first thing you would need to do is, do they have up-to-date talks. Up-to-date docs is very crucial for integrating with the API file developers. It will help you understand the real capability and you can also think of it as a very healthy indicator on how well their APIs are maintained or how serious that company or organization is with their API. The other factor to look into is how is the API architected, whether it's built on the rest, rails, SOAP, or GraphQL. We saw rest in GraphQL recently. Our SOAP is also a type of API architecture which is pretty old age now, not very commonly used that uses XML instead of JSON as requested response. Now maybe your developers don't have the GraphQL skills right now. Maybe that's not your technical strategy of the company. Maybe you're looking only for rest APIs right now. So factoring that in is a very important step.

don't want to sign a contract with a partner only to figure out that they only support GraphQL APIs, and you can't integrate with them because your entire architecture is based on REST. The other important factor to look into is performance. How is the API performant? What's the uptime? What's the request and response time? Is the API stable? Can it really scale with your business? Maybe a part of an international company spanning across multiple countries, and we know the sooner we launch the product, we'll be able to expand really fast. A third-party provider that I'm partnering with, can they support our scale tomorrow when we go from MVP to a full GA? Will they be able to support us? What are the SLAs that they provide? Is the API up 99.99% of the time or not? So, these are very important factors that you need to consider, collaborate with your developers and talk to them, and assess the API providers based on these criteria. The other important part is security as well. Now you may or may not pass.

sensitive data to the third party Partners, but you may be and it's very important for you to figure out that hey are they going to store your data in a very right manner. What's the security strategy? How are they protecting themselves against data attacks, Etc. or DDOS attacks, Etc. So it's very important to understand how secure your third party partner is, and finally like would they give you a right sandbox and testing environment when you are integrating with someone. You would first have to test their apis because you're marching into an unknown territory. You need to first test it. You need to see whether it is performing well or not, and all that is something you need to test. And finally, is the cost. If somebody's providing you a third-party API, there would be a charge to it. Is the cost justified? Is there a good Roi on that? Let me talk to you one of the examples back at PayPal. Our team wanted to integrate with tracking numbers of all shipping carriers so we can figure out that hey if this seller

has shipped an item, and they gave us back the tracking number. We can track that item and see whether the item was delivered and whether the tracking number is valid, so we can figure out that hey, this seller is not a fraud seller. They have actually shipped the item, the item has been delivered, and now we can release any hold if there's a dispute in the future between buyer and seller where the buyer claims that hey, I never received the item, but the seller says the item has been received. We can look at the API of the tracking number programmatically and Urgent the case. Now, PayPal is a global company present in like hundreds of countries, and we figured out that there are more than 400 different shipping provider tracking numbers in our system. One way would be to integrate with all those APIs manually of all those cases like calling FedEx APIs, UPS APIs, Royal Mail APIs, etc., which would be a nightmare. Rather than that, we figured out a partner called Aftership, which is a startup based in Hong Kong, and then we called their

single API, and they talk to each of the carriers' API and give us backup response. We went through all of this. Our compliance Department looked into how it how after ship stores the data, how afterships stores the customer address data, which you come as a part of tracking number, uh what is the cause. We figured out the cost that we paid to aftership per track number will be a smaller amount compared to building after team that integrates with all these APIs of different carriers, maintains them to modify exchanges something in their API. We would have to make that change. So basically, the mathematical business case made really sense for us to pay aftershave for every API call that we make rather than building out our own internal team. Focus just on maintaining this. However, there are always downsides when you are integrating with third-party. Okay, it's the biggest downside risk is you are dependent on your third party. Third parties basically capability to be up, basically to give you the right data. For example, if aftership server went

down, or if they just lose a tracking number, uh, we would not be able to close our disputes in the right way because we don't have data, and that basically would hit PayPal's reputation as a global company that could not solve a certain case where buyers and sellers are having a dispute, uh. Notion, and a good example, Notion has introduced this product called Notion AI, which internally calls OpenAI, uh, APIs or the large language models, but they both Duolingo Max and Notion AI are both strategically dependent on OpenAI right now. The more accurate OpenAI is, the more accurate they're able to predict something, the more accurate, uh, Notion's product would be. In a way, they are dependent on that. If tomorrow OpenAI closes something, repair access, or double discharge, or do something, the product, uh, Notion AI and Duolingo Max will be negatively impacted. So, understand the risk as well when you're connecting with third-party APIs. Let's dive into the second part where you build out the capability. You feel this is certainly great. Now let me

productize this capability in the form of an API and monitor. So in order to do that, the most important three aspects of it is number one value to customers. You have to figure out something that's extremely valuable to customers. If it is not valuable, people are not going to put the pains of integrating with your API, writing lengthy codes, uh, to make it work on their end. Second is a monetization and cost structure. If something is extremely expensive for me or where the cost does not justify the ROI, people would not connect to you. So you have to figure out what's the right monetization structure, the kind of business you are in, and how is the appropriate pricing for that API. And finally, is a solid documentation and developer relationship. A lot of PMS I have personally seen in different organizations often undermine the third aspect. You may have a great value, you may have a great monetization strategy, you can lock your partners in a contract, but if you do not have solid documentation and developer relationship, uh, people may not renew, people may not come back to you.

because the developers would have a hard time figuring out how the thing is working. Or people may just reject you outright in the beginning. That hey, our developers can't figure out. Understand that the end customer of your API is actually your developer sitting in a company. Is that developer that's your end customer who is integrating your API. And how good an experience you give to that developer or that developer community would go a long way in making your API a successful one and a widely adopted one. And that may also be a differentiating factor with your competitors. Stripe, for example, basically has gained so much popularity by using API documentation as a core value prop. They have one of the best documentation out there. And that is what they have used as their personal strength. All right, let's dive a little bit into the value. Your number one thing would be you have a product and you have to figure out like which part of these products provide enough value in a standalone manner that you can expose it in a form of an API. Let's take example of Spotify.

Spotify has several features like playing a song, creating a playlist, editing a playlist. If I were to be a PM at Spotify, and I have to launch my first API app to figure out which are the features that are most used by my customers, maybe do a market research to figure out which features would have the most appeal or use, or what are some of the most popular use cases, and then try to figure out and stack rank them, and then figure out which one would I expose by an API playing a song, maybe like we allow playing a song by an API so anyone who's having their website talking about music taste or music review can embed a Spotify plugin and play a song right on the website without leaving the website. Or maybe I want to do a sentiment analysis on your music days, and then having an access to a list of all the music in your playlist can help me figure out what kind of music you listen to or do a lot of cool things, but the first step is to figure out is there a need in the market, what are the

most valuable features that I can expose as a part of my API. And then you would do your Tech stack assessment. Now I may have this cool feature that I want to promote as an API, but this feature is buried deep down in a monolith and there is no way can expose it informant if an API. Or maybe it doesn't support the Json format. Maybe I cannot expose it to the micro service. Maybe I can do that, but it might take me six months to do that. So once you figure out a need, once you figure out the value, do work with your developers to figure out is this feasible or not. If this is feasible, what's the timeline to make it available as form of an API. And then as a PM, you can make a trade-off between the ROI of your whole thing and finally validate the API appetite. You may have figured out a few things from your market research, your Tech stack allows you to do that, but would people actually integrate with your API. Would they actually take the pain to integrate with the API and then pay on

top of it. A good way would be to do some sort of testing. Maybe offer that API for free and see how many people can integrate with that API just to test out the demand. Maybe you can launch a freemium model where people can connect your API and make like 10,000 requests per month for free. And above that, you will open the access slowly. Talking about opening the access slowly to more people, let's talk about demonetization model. Now, there are two ways you can expose your APIs. Number one, you can just make it publicly available. Anyone can use your API, anyone can sign up to it, anyone can integrate it, and you may define a model like maybe my API is completely free or maybe my API is free up to a certain threshold. The other model is a private model where you only invite certain partners to build on top of API, and there are many use cases of it. Maybe I'm building out a certain service for my customers where I don't want everyone to have that capability. I only want certain reputable

partners and many people do that when meta Facebook launch Facebook marketplaces. They initially opened their access to very few Partners, such as Shopify, etc., so users of those platforms can sync their catalog with Facebook marketplace. Now there are tons of players like that, but meta wanted to just open their APIs to a very handful of people in the beginning and just test with them and prove their model before opening the access to everyone. You can also choose to always have a private model, and I will share a personal story from my side where we went with a private one. But before that, like once you have decided whether you go public or private, you may figure out how do I monetize my API. Number one, maybe you just make your API free, and you monetize other services. If you integrate with our API, you get all the data for free, but if you need custom support on top of it, etc., maybe we charge for that. That can be a model that you may think of, whether it's good or not, it's up to you to decide what works in a

use case a very popular one is usage-based. Where you pay above a specific threshold. The first 10,000 API calls are free but everything above that is one cent per API Call. Etc. It can be a size space where you were hobbyists, uh, are given your API access for free and you have very limited features. But for an Enterprise use case where they have a lot of sophisticated demands whether they have a huge size you can just start charging them. The other one which is very interesting is revenue share where you make money where your partner makes money from API usage and you don't charge a flat API fee. Back in PayPal, uh, we built out an API that would expose all the shipping data of a customer so if I'm a seller I need to ship a certain item I would need what's my buyer addresses what my Warehouse address is what is the size of the package what is the dimension of the package and based on that data I can purchase a shipping label and print it online so at PayPal we expose this API but we

didn't want every shipping provider out there to consume our API and start giving value to PayPal customers. That would dilute our offering, so we just launched this API as a private model, selected a couple of Partners in select regions, like one in Europe, one in North America, and just partnered with them. We gave them the API access. Now, these companies had access to PayPal buyer's data, and all PayPal sellers will go to their platform to purchase shipping labels. The monetization model we did was Revenue share. The amount of money you make on shipping label, you just give a part of Revenue to us. The reason we did that, and we did not charge a flat API fee, is because the amount of money you make on each shipping label was hugely different. Like on certain corridors and certain heavyweight items, I would make a lot of money. You know, certain corridors, I would make less money. We did not want to lose money on the table, and we did not want to overcharge our partner. So we went with a REV share model that every time you make

money X percentage of your revenue is what you would share with PayPal. So that's one monetization model where you do Revolution. And finally, finally, the most important part is sharpen developer relationship. Once you build out an API, especially if your API is a public API where multiple people will be connecting with it, make sure that your developer relationship is very strong. And that starts with making a documentation. Make sure your documentation is usable, it's easy to understand, and up to date. And we give an example of stripe. How stripe is a gold standard for developer documentation. Make sure you share your code samples and libraries so people can readily integrate with your API. One key metric I as a PM take for my API is time to hello world, which is basically the moment a developer starts integrating with my API. How soon can they integrate with their API and come up with a First Response? Definitely it can be in a sandbox environment, but the faster they can do it, that means that I have my documentation really well laid out. I have write code samples. I have right

libraries given out in my documentation so the developers can leverage and do that and finally is customer support. There may be multiple nuanced edge cases that two different partners may have or they may have multiple queries, etc. A good way to support all of them would be to have good customer support where you can provide technical support to all the developers integrating with your APIs. Finally, as a bonus, we would talk about some of the useful tools that you can use as an API product manager. We recently found this tool called Blobber, which is amazing. It builds out API portals so you can build out your whole API portals, host your API documentation, and you can as well as Define your pricing API monitoring on the dashboard everything Global support. Now I understand many large organizations have their own API portals which you would use but if you're a PM in a startup or if you're just starting out your API journey Blobber is a good tool to understand. Postman is something we just saw an example it allows you to test different

apis right from a desktop. You don't have to write any code, just put in the request, put in the URL and endpoint, and you can test that API, how it behaves in production. Finally, Stripe provides a tool called Matlock, which allows you to write documentation for API in a very stylish, in a very good fashion, and it's an amazing tool that you can check out. Finally, let's look up some of the examples of productized API we have seen recently, a trend around people like monetizing their API, right? It recently announced that how they want to just charge for their APIs. A lot of companies are building out different APIs that they're exposing out in the public because in this economy where everyone is out building great startups, great tools, great collaborative products, APIs help a lot in doing that. Here's an example of a Twitter where Twitter basically productize their API and they are giving out three different tiers like 1500 tweets per month you get for free but above that you need to pay you can come into a basic pricing category.

on an Enterprise pricing category. Similarly, Google Map have they provide API where they provide you API to give out the list of maps, etc., and up to 1000 requests they don't charge you anything, and above that they start charging you. Similarly, Reddit is an example where they came out with their own API. My current company Square also provides a ton of APIs for developers to build tools where they can get access to users catalog data, etc. PayPal provides a lot of APIs for building out your own checkout on any website that you build, and we talked about a very specific use case around shipping where we build out a third-party APIs specifically for shipping providers such as ShipStation, Shippo, etc., where they can consume PayPal data to allow sellers to purchase shipping labels, which is a very nuanced and a very specific edge case where we had a very specific and different pricing model. But in these cases here, these product APIs, most of the pricing model that you see would be around usage-based up to a certain or you're free, and above that you start paying based on

how much your usage is a time. It's 8:35. Thank you all for the session. API is such a broad topic. I hope that I was able to give some value in the limited time we have, but would love to connect future through Department of product to type to dive deeper into more API related topics. Today's session was brought to you by our partners at Sandford senberg believes the conversations are at the heart of building relationships and getting things done, and they have built the world's most proven conversation platform for mobile apps across chat, voice, and video. Sender has helped over 1200 businesses worldwide improve customer retention, conversion, and support with their in-app conversations platform. You can find out more by going to sendbird.com.

How to create an API Product Strategy

The Department of Product is a global community of over 40,000 product managers, tech founders, designers and engineers from companies including Netflix, Google, Apple, Uber, Spotify, Microsoft and more.

Stay up to date with our weekly briefing, deep dives and Knowledge Series on Substack here: https://departmentofproduct.substack.com/

