//pragmatic leaders

Types of API

Reading time
6 min
Section
Technology for Product Manager
6 min left0%
types of api0%
6 min left
APIs are the business layer access points — they expose the right data and functions to the right parties, no more, no less.
Talvinder Singh, from a Pragmatic Leaders session on APIs

APIs are the glue that connects software systems. They let your product talk to other products, services, or internal components — but in a controlled, secure way. The actual job of an API is to expose business logic or data to authorized parties, nothing more.

If you cannot answer what type of API you need and why, you are not ready to design or specify the integration.

Four access-based API types define who uses them

APIs are often categorized by whom they serve and how they are exposed. The four main types are:

  • Public APIs (Open APIs): Available to any developer with minimal onboarding. They are “public” but usually require registration for API keys. Example: Google Maps API. You don't need special permission beyond registration to use it.

  • Partner APIs: Exposed only to strategic business partners under contractual agreements. They require a formal onboarding process and are not publicly documented. Used for B2B integrations where trust and control are critical.

  • Internal APIs (Private APIs): Used strictly within an organization. These APIs connect different teams and services internally to improve productivity and modularity. They are never exposed outside the company.

  • Composite APIs: These orchestrate multiple underlying APIs or services into a single interface. Useful when a client needs to perform complex operations that span multiple systems.

The distinction is critical because it shapes your security model, documentation, onboarding, and governance processes.

India’s product ecosystem includes all these types. For instance, Razorpay exposes public APIs for payments, partner APIs for select fintech partners, and private APIs internally between services.

// thread: #product-tech — API type discussion
Meera (Backend Lead)Our authentication service exposes a private API only used by the mobile and web teams.
Rahul (Integration PM)For our partner banks, we have a partner API with strict SLA and contract terms.
Neha (Frontend)Google Maps is a classic public API — anyone can use it with a key.
YouComposite APIs will help simplify the payment flow by bundling auth, payment, and notification calls.

Three dominant API protocols you must know

Understanding API types also means knowing the protocols they use. The most common are:

  • REST (Representational State Transfer): The most popular style today. Uses HTTP verbs (GET, POST, PUT, DELETE) and JSON or XML payloads. REST APIs are easy to build and consume, making them the default choice for web and mobile apps.

  • SOAP (Simple Object Access Protocol): An older, XML-based protocol with strict standards for security and transactions. SOAP APIs are common in legacy enterprise systems and sectors like banking or telecom where reliability and formal contracts matter.

  • RPC (Remote Procedure Call): Includes XML-RPC and JSON-RPC. These treat API calls like function calls — you invoke a method with parameters and get a response. RPC is simpler than SOAP but less flexible than REST.

Each protocol has trade-offs. REST’s simplicity and lightweight nature suit most modern products, especially consumer-facing ones like Flipkart’s mobile app. SOAP’s rigidity fits regulated Indian banks that require formal message contracts.

Content types define how data is formatted and transmitted

APIs communicate data in specific formats indicated by the Content-Type header. Common types include:

  • application/json: The most widely used format today, easy to parse and human-readable.

  • application/xml: Used by SOAP APIs and some legacy systems.

  • x-www-form-urlencoded: Often used in form submissions or simple key-value pairs.

Choosing the right content type impacts client compatibility and developer experience.

The actual job is making the right API choice for your product scenario

Not every product needs a public API. Not every integration demands SOAP. The trap is to pick a technology because it sounds modern or because your competitor uses it.

Here is the uncomfortable reality: the API you choose must fit your product’s user, security model, and integration needs.

  • If you are building a consumer-facing app that integrates with many third parties, a public REST API is usually best.

  • If you are exposing sensitive data to a few partners, a partner API with strict onboarding and monitoring is required.

  • If you want to decouple your monolith into services internally, build private APIs with strong authentication.

  • If your client workflows require multiple backend calls, use composite APIs to reduce client complexity.

Indian companies like Swiggy use private APIs internally to separate order management and delivery tracking, partner APIs for restaurant partners, and public APIs for payment gateways.

The API lifecycle includes design, documentation, security, and monitoring

Building an API is not just coding endpoints. You must design it with clear contracts, document it for developers, secure it against misuse, and monitor usage and performance.

For example, Flipkart’s public APIs require API keys, rate limiting, and detailed docs. Razorpay’s partner APIs include SLAs and audit logs. Internal APIs at PhonePe have strict versioning and backward compatibility requirements.

Your job as a PM is to ensure these aspects are planned and resourced appropriately.

Field exercise: Classify APIs in your product ecosystem

// exercise: · 15 min
Map your product’s API landscape
  1. List all the APIs your product exposes or consumes.
  2. For each, classify as Public, Partner, Internal, or Composite.
  3. Note the protocol used: REST, SOAP, or RPC.
  4. Identify the main consumers of each API (internal teams, partners, public developers).
  5. Highlight any gaps or risks you see (e.g., missing documentation, weak security).

Meeting scene: Choosing the right API type for a new integration

// scene:

Product strategy meeting at a Series B fintech startup in Bangalore

CTO: “We want to expose our payments data to select partners for reconciliation. Should we build a public API or something else?”

You (PM): “Given the sensitivity, a partner API with strict onboarding and contract terms is safer than a public API.”

Engineering Lead: “We have internal APIs already for our services. Should we expose those directly?”

You (PM): “No, internal APIs are not designed for external consumption. We need a dedicated partner API layer with proper security.”

CTO: “What about using REST or SOAP here?”

You (PM): “REST is simpler and faster to build. SOAP offers more formal contracts and security, but adds complexity. Our partners prefer REST.”

Engineering Lead: “Okay, we'll design a REST-based partner API.”

The team agreed on a partner API designed for external B2B use with REST protocol and OAuth security.

// tension:

Balancing security, usability, and partner needs in API design

Judgment exercise: API type decision at a healthtech startup

// learn the judgment

You are the PM at a healthtech startup in Pune building a patient data platform. The platform must share lab results with hospitals, diagnostic centers, and insurance partners. Some partners want real-time data; others want batch exports. The startup currently has internal REST APIs but no external API layer.

The call: Which API types should you build to serve these partners? Justify your choice.

Your reasoning:

// practice

You are the PM at a healthtech startup in Pune building a patient data platform. The platform must share lab results with hospitals, diagnostic centers, and insurance partners. Some partners want real-time data; others want batch exports. The startup currently has internal REST APIs but no external API layer.

Your task: Which API types should you build to serve these partners? Justify your choice.

your reasoning:

0 chars (min 80)

API protocols in practice: REST, SOAP, and RPC examples

India’s large IT services firms and legacy banks still use SOAP APIs extensively because they offer formal contracts, WS-Security, and transactional guarantees. For example, SBI’s payment gateway uses SOAP for core banking integrations.

Startups and consumer apps like Swiggy, Razorpay, and PhonePe almost exclusively use REST APIs. REST’s lightweight JSON payloads are a better fit for mobile and web clients, accelerating development.

RPC-style APIs are rare in new Indian products but appear in some internal microservices where simplicity and speed matter more than flexibility.

Composite APIs simplify complex workflows

Composite APIs wrap multiple backend calls into one. For example, an e-commerce checkout composite API might:

  • Verify inventory via an inventory service API
  • Calculate shipping via logistics API
  • Process payment via payment gateway API
  • Generate order confirmation

This reduces round trips for clients and simplifies error handling.

Indian companies like Flipkart use composite APIs internally to optimize mobile app performance over mobile networks.

Video: Types of API explained in 5 minutes

Where to go next