API 제품 전략: 통합, 수익 창출 및 문서화

### API 제품 전략: 주요 개념 및 모범 사례
* 🛠 API는 애플리케이션 프로그래밍 인터페이스의 약자로, **식당에서 음식을 주문하는 것처럼 두 시스템이 서로 통신**할 수 있게 해줍니다.
* 📝 "요청과 응답은 **클라이언트가 서버에 요청을 하고 응답을 받는 API의 핵심적인 측면**입니다."
* 🔗 "엔드포인트는 리소스에 액세스하기 위해 API 요청이 이루어지는 URL로, 예를 들어 앨범 목록을 가져오기 위해 **Spotify API에서 'albums' 엔드포인트**를 호출하는 것과 같습니다."
* 📚 "좋은 API 문서에는 **요청 및 응답 형식, 샘플 요청 및 응답**에 대한 정보가 포함되어 있습니다."
* 🔄 "REST API는 엔드포인트에 기반한 아키텍처 스타일인 반면 **GraphQL은 클라이언트가 특정 응답을 요청할 수 있는 쿼리 언어**입니다."
* "API와 통합할 때 제품 관리자는 **타사 API에 연결하여 새로운 기능을 빠르게 추가**하거나 **자체 API를 구축, 제품화 및 수익화**할 수 있습니다."
* 📈 "타사 API와 통합할 때는 먼저 내부 요구사항을 파악하고, **API 상태를 평가**하고, 아키텍처, 성능, 보안 및 비용을 고려하고, 종속성의 위험을 이해하는 것이 중요합니다."
* 💡 "자체 API를 구축하고 수익을 창출할 때는 **고객에게 가치를 제공**하고, **적절한 수익화 전략**을 정의하며, **탄탄한 문서와 개발자 관계**를 유지하는 데 집중하세요."
* 🛠 API 제품 관리자에게 유용한 도구로는 **API 포털을 구축하는 Blobber, API를 테스트하는 Postman, 세련된 API 문서를 작성하는 Stripe Matlock**이 있습니다.
* 💰 "**트윗 액세스에 대한 단계별 요금제**"를 제공하는 트위터, **사용량 기반 요금제**를 제공하는 Google 지도, 다양한 사용 사례에 맞는 API를 제공하는 **Square, PayPal, Reddit 및 다양한 배송업체** 등 많은 기업이 API를 제품화하여 수익을 창출하고 있습니다.

Square의 제품 책임자인 Abhishek은 용어, 타사 API 통합, API의 제품화 및 수익화 등 API 제품 전략에 대해 설명했습니다.

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/



Department of Product

Square의 제품 책임자인 Abhishek이 API 통합, 출시 및 수익 창출에 대한 경험을 공유합니다.

이 세션에서는 API의 의미, 요청 및 응답, 엔드포인트와 같은 필수 API 용어를 다룹니다.

아비셰크는 이러한 개념을 실생활에 비유하여 설명하므로 청중이 더 쉽게 이해할 수 있습니다.

이 세션은 효과적인 API 전략을 개발하고자 하는 제품 담당자에게 유용한 인사이트를 제공합니다.

API 엔드포인트는 리소스가 위치한 URL이며, 이러한 엔드포인트를 요청하면 영국에 대한 데이터를 얻기 위해 대기질 API를 호출하는 예에서 볼 수 있듯이 원하는 데이터가 포함된 응답을 받을 수 있습니다.

좋은 API 문서는 응답의 각 필드와 요청 본문에 대한 명확한 설명을 제공하고 샘플 요청 및 응답의 예를 제공하여 API를 쉽게 통합하고 이해할 수 있도록 도와주므로 필수적입니다.

REST API는 엔드포인트, 요청 형식 및 응답 형식을 정의하는 것을 기반으로 하는 API 개발에 널리 사용되는 아키텍처 스타일이며, GraphQL은 인기를 얻고 있는 또 다른 핵심 용어로 REST와는 다른 접근 방식을 제공합니다.

REST는 다양한 데이터 요청에 대해 특정 엔드포인트에 의존하기 때문에 리소스가 과잉 또는 부족할 가능성이 있는 반면, GraphQL은 단일 쿼리 내에서 맞춤형 데이터 요청이 가능하므로 데이터 검색이 최적화됩니다.

타사 API와 통합하면 적은 노력으로 새로운 가치를 빠르게 추가할 수 있으며, 자체 API를 구축하여 수익을 창출하면 기존 기능을 제품화할 수 있습니다.

타사 API를 사용하면 최소한의 노력으로 제품 출시 속도를 크게 높일 수 있으며, 기존 기능을 독립적으로 제품화하고 수익화하면 다른 개발자에게 자체 API를 제공할 수 있는 기회를 얻을 수 있습니다.

타사 API와 통합하기: 단계별 가이드

타사 API와 통합하기 전에 먼저 내부 요구 사항과 제품 및 회사 전략과의 연계성을 평가하는 것이 중요합니다.

제공업체를 선택하는 과정에서 API의 문서, 아키텍처, 성능, 보안, 테스트 환경 및 비용을 고려하는 것이 중요합니다.

또한 성공적인 통합을 위해서는 API 상태 평가 및 의사 결정에 개발자 참여가 필수적입니다.

타사 API를 사용하여 배송 추적하기

PayPal은 Aftership과 통합하여 400개가 넘는 다양한 배송업체 번호를 추적하므로 각 배송업체와 수동으로 통합해야 하는 번거로움을 피할 수 있습니다.

하지만 이 파트너십에는 정확한 데이터를 제공하는 Aftership의 역량에 의존해야 한다는 단점이 있으며, 이는 PayPal의 평판에 부정적인 영향을 미칠 수 있습니다.

API에 기능을 구축할 때는 고객에게 제공하는 가치에 집중하고, 올바른 수익화 구조를 수립하며, 장기적인 성공을 위해 탄탄한 문서화 및 개발자 관계를 우선시하는 것이 중요합니다.

성공적인 API 출시를 위한 주요 전략

개발자는 API의 최종 고객이므로 잘 문서화된 Stripe의 인기에서 알 수 있듯이 좋은 개발자 경험을 제공하는 것이 성공에 매우 중요합니다.

It seems there was no text provided for me to work on.

Please provide the sentence you'd like me to analyze, and I'll be happy to bold the most crucial phrase for you!

API에 노출할 가장 가치 있는 기능을 파악하는 것이 첫 번째 단계이며, 이는 시장 조사와 사용 사례를 기반으로 우선순위를 정하여 결정할 수 있습니다.

Please provide the sentence you would like me to analyze and bold the key phrase in.

가치를 파악한 후에는 기술적 실현 가능성을 평가하고, ROI에 따라 절충점을 찾고, 테스트와 잠재적인 부분 유료화 모델을 통해 API의 수요를 검증하는 것이 중요합니다.

API 액세스 수익화 및 관리 전략

메타는 처음에는 모델을 테스트하고 입증하기 위해 Shopify와 같은 일부 파트너에게만 액세스를 제한한 후 모든 사람에게 개방했습니다.

API의 수익 창출 모델에는 유료 추가 서비스와 함께 무료 액세스 제공, 사용량 기반 요금 구조 또는 수익 공유 모델이 포함될 수 있습니다.

포괄적이고 사용자 친화적인 문서, 코드 샘플, 빠른 통합 프로세스를 통해 개발자와의 강력한 관계를 구축하는 것은 성공적인 API를 위해 매우 중요합니다.

우수한 고객 지원은 개발자가 API와 통합할 수 있도록 지원하는 데 매우 중요합니다.

블러버, 포스트맨, 매트록과 같은 도구는 포털 구축, 테스트, 문서화를 통해 API 제품 관리자를 도울 수 있습니다.

현재 많은 회사들이 API 기반 솔루션에 대한 증가하는 수요를 충족하기 위해 트위터, Google 지도, Reddit과 같은 사용량 기반 또는 계층화된 요금 모델을 통해 API를 제품화하고 있습니다.