API: What Is It?

APIs are the backbone of modern software products. They enable different systems, teams, and companies to collaborate by providing controlled access to data and functionality. If you do not understand APIs, you will struggle to grasp how your product fits into the larger technology ecosystem — and how to make strategic technology decisions.

The trap is thinking of an API as just a technical detail. The actual job is to see APIs as the contract your product offers to the outside world and to internal teams. This contract defines how value flows and who can participate.

What is an API, really?

API stands for Application Programming Interface. It is a set of rules and protocols that allows one software application to access services or data from another. Think of it as the waiter between you and the kitchen. You place your order (request), and the waiter brings back your food (response). You don’t need to know how the kitchen works, just how to ask for what you want.

Talvinder often describes APIs as the business layer access to authorized parties. This means APIs expose business logic — not just raw data — and control who can do what. For example, your product might expose an API to partners to fetch user transaction history, but only if they have the right credentials.

Web services vs APIs

You will hear the terms "web services" and "APIs" used interchangeably, but there is a subtle difference:

• Web services are a kind of API that operate over a network using standard protocols like HTTP. They are a subset of APIs.
• APIs include web services but also other forms like library calls or operating system interfaces.

For product managers, the focus is usually on web APIs because they enable your product to integrate with other products and services over the internet.

The four types of web APIs

Talvinder categorizes web APIs into four types, each with distinct use cases and access controls:

Understanding which type your product offers or consumes helps you design the right security, documentation, and developer experience.

API architectural styles: SOAP, XML-RPC/JSON-RPC, REST

There are multiple API protocols and styles. The most common ones you will encounter are:

• SOAP (Simple Object Access Protocol): A protocol that uses XML for messaging. It is highly standardized and supports complex operations but is heavier and more rigid.
• XML-RPC / JSON-RPC: Remote Procedure Call protocols that use XML or JSON to encode calls and responses. Simpler than SOAP but less popular today.
• REST (Representational State Transfer): An architectural style that uses standard HTTP methods (GET, POST, PUT, DELETE). It is lightweight, stateless, and the most widely used API style today.

Most modern Indian startups use REST APIs for their simplicity and scalability. SOAP is still common in enterprise contexts with legacy systems.

Content types and data formats in APIs

APIs exchange data in specific formats called content types. Common ones include:

• application/json: The most popular format today, easy for web and mobile apps to consume.
• application/xml: Used in older systems and SOAP APIs.
• x-www-form-urlencoded: Used for simple form data submissions, often in web forms.

Your product may support multiple content types depending on your clients’ needs.

Real-world API examples

To get a feel for APIs, Talvinder points to several public API endpoints where you can experiment:

• Dummy REST API Example
• JSON Placeholder
• Reqres.in
• Countries GraphQL API

These sites let you make HTTP requests and see JSON responses. This hands-on exposure helps you understand how requests and responses work in practice.

Why every product manager must understand APIs

Your product will either expose APIs, consume APIs, or both. This shapes:

• Product architecture: Microservices and modular design depend on well-defined APIs.
• Partnerships and integrations: APIs are the language you use to connect to partners like Razorpay or Swiggy.
• User experience: API reliability and performance affect the end-user directly.
• Security and compliance: APIs are gateways that must be secured and audited.

If you cannot answer: What APIs does my product offer? Who uses them? How do they work? — you are not ready to lead a technical product.

The invisible product behind your product: APIs

Talvinder often says: the API is the business interface. It is the product your partners and internal teams use, even if they never see your UI. For example, Flipkart’s internal teams rely heavily on APIs to sync inventory, pricing, and orders across their massive ecosystem.

This is what week one looks like for most new PMs on a platform product: endless questions about API specs, authentication, rate limits, and error handling. If you don’t have a mental model for APIs, you will drown.

Authentication and authorization: controlling API access

APIs expose valuable data and functionality, so access must be tightly controlled. Common methods include:

• API keys: Simple tokens passed with each request.
• OAuth 2.0: A secure protocol allowing delegated access, often used for user data.
• JWT (JSON Web Tokens): Tokens that encode user identity and permissions.

Each has trade-offs in security and complexity. As a PM, you need to understand these enough to make informed decisions about partner integrations and compliance.

API versioning and backward compatibility

Products evolve, and so do APIs. But changing an API can break existing clients. This is why API versioning is critical.

Versioning strategies include:

• URL versioning: /v1/orders, /v2/orders
• Header versioning: specifying version in HTTP headers

You must coordinate API changes carefully and communicate clearly with consumers to avoid disruptions.

Composite APIs: simplifying complex workflows

Sometimes a single user action requires multiple backend calls. Composite APIs bundle these into one call, reducing latency and complexity for clients.

Meesho uses composite APIs to aggregate product listings, pricing, and seller ratings into one response. This improves mobile app performance on low-bandwidth networks common in tier-2 and tier-3 cities.

Field exercise: Explore a public API

The PM’s role in API design and documentation

You are not expected to write code, but you must:

• Define clear API requirements based on user and partner needs.
• Ensure API documentation is complete, accessible, and up to date.
• Collaborate with engineering to design APIs that are easy to use and maintain.
• Monitor API adoption, errors, and performance metrics.

Good API design is a competitive advantage. Razorpay’s success is partly due to their developer-friendly APIs and documentation.

Common pitfalls with APIs in product management

• Treating APIs as an afterthought rather than a product.
• Overloading APIs with too many responsibilities, making them hard to maintain.
• Poor versioning leading to breaking changes and frustrated partners.
• Inadequate security exposing sensitive data.
• Lack of monitoring causing outages and poor user experience.

Avoid these by involving yourself early in API planning and treating your API as a first-class product.

Judgment exercise: API prioritization in a fintech startup

From the field: Why APIs are the invisible product

Where to go next

• If you want to deepen your technical fluency: Technical Concepts for Product Managers
• If you want to learn how to manage integrations: Partner and Ecosystem Management
• If you want to understand product architecture: Microservices and Modular Design
• If you want to improve API documentation skills: Writing Effective API Docs