You often hear frontend developers and backend developers discussing APIs, yet you may feel completely confused. Sometimes you need to integrate third-party platform services, but you don’t know how to write interface documentation—simply because you don’t even know what an API is.

This article explains the concept in a clear and easy-to-understand way. Hopefully, you’ll gain something useful after reading it.

Openness and sharing are core values of the internet. They represent a service model and a special type of product. Today, almost all large internet companies operate their own open platforms.

If you position yourself only as a feature-focused product manager—concerned mainly with UI interactions, operation flows, and surface-level architecture—then you may not feel the need to understand open platforms. However, if you want to view products from a higher strategic level, you must understand platform ecosystems: what can be opened externally, who the services are for, and which high-quality ISVs (Independent Software Vendors—companies specializing in software development, production, sales, and services) you can collaborate with to build a stronger ecosystem.

Understanding APIs

When talking about development platforms, APIs are unavoidable. As product managers, we don’t need to understand every technical detail—we only need to know what an API is, what it’s used for, and what elements it contains.

1. What is an API?

In daily life, we encounter many “interfaces,” such as HDMI ports or USB ports. We know that plugging into a specific interface enables a certain function—for example, inserting a USB drive into a computer allows file transfer. We don’t need to know how it works internally; we only care about what it can do.

Program interfaces work the same way. They encapsulate internal logic like a sealed box, leaving only an opening. As long as you connect to that opening, you can use the function inside.

2. What are APIs used for?

In real development, when frontend and backend systems exchange data, frontend developers usually ask for APIs rather than implementation details. For example, if an app needs to display current weather information, the frontend simply connects to a weather API.

Opening APIs also allows third-party applications to easily integrate features such as third-party login, online payments, and more.

3. Key elements of an API

• API endpoint — the request URL.

• Request method — usually HTTP GET or POST.

• Request parameters — the data you send.

• Response data — the result returned after the request, typically in JSON or XML format.

• Error codes — part of the response, explaining what went wrong when exceptions occur.

For example, if your app needs parcel tracking, you integrate a logistics tracking API. The tracking number entered by the user is the request parameter, and the delivery status and location updates are the response data.

The Purpose of Building an Open Platform

1. Provide foundational services for third-party developers

By opening APIs, platforms allow developers to directly call mature services such as WeChat Login, WeChat Pay, Alipay, ride-hailing, hotel booking, and more.

This not only saves developers huge amounts of time, but also promotes the platform’s brand. Most importantly, it enables third-party applications to better meet user needs. For example, a transaction-heavy app without WeChat or Alipay payment—even if well designed—would attract very few users.

2. Attract ISV partners through platform advantages

ISVs can integrate their products into the platform, forming a cooperative ecosystem that delivers one-stop services to users.

DingTalk, for example, integrates many third-party applications such as Shimo Docs, Yikaibao Expense, and voting tools—covering most enterprise management needs within a single platform.

Another example is Ele.me’s developer platform, which introduces ISVs to provide comprehensive O2O restaurant services, including recruitment, restaurant management systems, hardware devices, photography, marketing, and even legal consulting—allowing merchants to find everything they need in one marketplace.

3. Meet users’ personalized needs

No product can satisfy every user. Some users have highly customized requirements.

Through open platforms, users with development capabilities can extend or modify existing services to meet their own needs.

For instance, if you operate an e-commerce public account and want to add product search, ordering, order management, and tracking features, third-party platform development becomes necessary.

General Process of Building an Open Platform

1. Define target users and service scope

Before building a developer platform, it’s essential to clarify who the target users are, what problems the platform solves, and in which scenarios it will be used.

For example, food delivery platforms such as Ele.me and Meituan provide ordering services but not cashier systems. Restaurant POS vendors can integrate with these platforms so that orders placed online are directly received and processed on the cashier system. This requires APIs for store management, product uploads, order synchronization, and status updates.

Similarly, merchants may face cash-flow issues, which allows the platform to introduce ISVs offering financial or loan services.

2. API design

After defining the service scope, the next step is API design. This is not solely a PM responsibility—it requires close collaboration between technical teams and platform product managers.

API design includes endpoint naming, parameter formats, response structures, and field naming. Clear naming greatly improves readability—for example, product.add and product.update clearly indicate their functions.

3. Authorization and review

Authorization ensures data security and prevents unauthorized access. Developers must register and apply for access, and higher-level permissions require stricter qualification reviews.

For ISV providers and merchant IT integrations, the platform must also design onboarding processes, documentation, and FAQs. A typical ISV onboarding flow includes:

Business negotiation → Become a service provider → Qualification review → Create application → Development & testing → Application review → App listing → Commercial acceptance