An API is the business layer access point — the handshake between your product and the outside world. If you don’t understand it, you will miscommunicate with your engineers and miss strategic opportunities.
APIs are the invisible glue that connects modern products to their users, partners, and other systems. They are not just technical plumbing — they are the business layer access points that control who can do what with your product's data and capabilities.
If you do not understand what an API is and how it works, you risk misaligning your product strategy and confusing your engineering team. The actual job of a PM includes knowing enough about APIs to ask the right questions and make informed trade-offs.
This lesson will ground you in what APIs are, the different types you will encounter, and how to think about them as a product manager.
What an API actually is: The business layer access point
An API, or Application Programming Interface, is a contract between two software systems. It defines how one system can request data or actions from another, and what responses to expect.
Think of an API as a business layer access point — it exposes specific capabilities of your product to authorized parties, whether that is your mobile app, a partner company, or internal teams.
The API controls access, enforces rules, and structures communication. It is not the user interface, not the database, and not the internal codebase. It is the boundary where your product says: "Here is what you can ask me to do, and here is how I will respond."
This perspective is critical. APIs are the product interface for other products and services. They carry value and constraints just like a user-facing feature.
The difference between web services and APIs
You will often hear "web services" and "APIs" used interchangeably, but there is a subtle difference.
- Web services are a specific kind of API accessible over the web, usually using HTTP protocols.
- APIs can be broader — they include libraries, operating system calls, or any interface between software components.
For product managers working with digital products, the focus is mostly on web APIs — the endpoints your app or partners call over the internet.
Four common types of web APIs
When managing APIs in your product, you will encounter different types depending on who uses them and how.
| Type | Description | Who uses it | Example in India |
|---|---|---|---|
| Public API | Openly available to external developers and partners | External developers | Razorpay’s payment API |
| Private/Internal API | Used only within your company’s systems | Internal teams | Swiggy’s internal order management API |
| Partner API | Shared selectively with trusted partners | Specific external partners | Flipkart’s vendor integration API |
| Composite API | Aggregates multiple APIs into one call | Internal or external users | PhonePe’s unified payment API |
Understanding these types helps you set access policies, security, and developer experience expectations.
Common API protocols: SOAP, XML-RPC/JSON-RPC, REST
APIs use different protocols or architectural styles for communication. The most relevant for modern products are:
- SOAP (Simple Object Access Protocol): A strict protocol using XML. Legacy systems and enterprises still use it for formal contracts and security.
- XML-RPC / JSON-RPC: Lightweight remote procedure call protocols using XML or JSON. Less common now but still in use.
- REST (Representational State Transfer): The dominant style today, using HTTP verbs (GET, POST, PUT, DELETE) and typically JSON payloads.
Most Indian startups and SaaS companies use REST APIs because they are simple, scalable, and easy to work with.
Your engineering team will tell you which protocol you support. Your job is to know enough to understand implications:
- SOAP APIs tend to be more rigid but offer enterprise-grade security.
- REST APIs are more flexible but require careful versioning and documentation.
Content types and data formats in APIs
When you call an API, you send and receive data in specific formats. The most common content types are:
application/json: The standard for modern APIs, lightweight and easy to parse.application/xml: Older APIs or those requiring strict schema validation.x-www-form-urlencoded: Used for simple form data submissions.
As a PM, you should understand these terms so you can read API documentation and discuss integration needs with your team or partners.
Real-world examples and resources
Here are some publicly accessible APIs that you can explore to get a feel for how APIs work in practice:
- Dummy REST API Example — sample data for testing.
- JSONPlaceholder — fake online REST API for testing.
- Reqres.in — a hosted REST-API ready to respond to your AJAX requests.
- Countries GraphQL API — a public GraphQL API for country data.
These resources are useful for prototyping or understanding API responses without needing to build your own backend.
How APIs show up in product management
APIs are not just developer tools. They shape your product strategy and user experience.
- Integration opportunities: APIs let you partner with other companies or platforms. For example, Razorpay’s public payment API enables thousands of Indian merchants to accept online payments seamlessly.
- Platform play: If your product exposes APIs, you become a platform. This changes your business model, your roadmap, and your developer relations priorities.
- Internal efficiency: Private APIs enable modular product development. Swiggy’s internal APIs allow separate teams to build order management, delivery tracking, and customer support independently.
- Security and compliance: APIs are gateways. You must ensure only authorized access, data privacy, and audit logging.
- Performance and reliability: API latency directly impacts your product’s responsiveness. You must prioritize backend stability.
What every PM should ask about APIs
When working with APIs, here are the critical questions you should ask:
- Who are the consumers of this API? Internal engineers? External partners? Third-party developers?
- What business value does this API unlock? New revenue streams? Faster feature delivery? Improved customer experience?
- How is access controlled? Authentication, authorization, rate limiting?
- What are the failure modes? How do we handle downtime or incorrect responses?
- How will we version and evolve the API without breaking existing consumers?
- What documentation and developer support do we provide?
These questions help you own the API roadmap as a product, not just a technical interface.
MeetingScene: Discussing API strategy at a SaaS startup in Bangalore
Product and engineering sync at a Series B B2B SaaS startup in Bangalore
You (PM): “We need to decide if we expose a public API for our invoicing module or keep it private for now.”
Engineering Lead: “Public API means more support overhead and backward compatibility concerns. Private API lets us iterate faster.”
Sales Head: “Some of our enterprise customers want API access to integrate with their ERP systems. That could be a selling point.”
You (PM): “Let’s prioritize building a partner API first, with limited endpoints, and a clear SLA. We can expand to public API after validating demand.”
This trade-off balances customer needs with engineering capacity and risk management.
Choosing between rapid internal iteration and opening the product to external partners
FieldExercise: Explore an API yourself (10 min)
Pick one of the public APIs listed above. Use a tool like Postman or curl to:
- Make a GET request to fetch data (e.g., list of users or countries).
- Make a POST request if supported to create or modify data.
- Observe the response format and status codes.
- Note how the API documentation guides you through these calls.
This hands-on experience will demystify APIs and prepare you for conversations with engineers and partners.
Test yourself: The API integration decision
You are PM at a fintech startup in Mumbai preparing to launch a new payments product. The engineering team proposes exposing a REST API for merchants to integrate payments directly into their apps. However, the sales team says only a handful of large merchants need API access initially, and the support cost could be high. The CTO suggests delaying the public API and focusing on a partner API first.
The call: What should you recommend regarding API exposure and why?
Your reasoning:
Where to go next
- If you want to deepen your understanding of product strategy: Product Vision and Strategy
- If you want to learn how to work effectively with engineering teams: Engineering Collaboration for PMs
- If you want to explore API design and developer experience: API Product Management
- If you want to master stakeholder communication: Effective Stakeholder Management
- If you are preparing for technical product management interviews: Technical PM Interview Prep