APIs Explained: How Software Talks to Software

Almost nothing your business runs on is a single program any more. Your website checks stock in a warehouse system, your accounting tool pulls transactions from the bank, your HR platform files leave with payroll, and your customers log in with Singpass. Every one of those hand-offs happens through an API — an application programming interface. If you have ever wondered what people mean when they say two systems "talk to each other", the answer is almost always: through an API.

This is the foundational article for the integration cluster. It stays deliberately plain-English; the sibling pieces on API management and API security assume you already know what an API is, and this is the page that answers it.

What an API actually is

An API is an interface — a menu of things one program will do for another, written down precisely enough that a machine can rely on it. The classic analogy is a restaurant: you (one program) read the menu and place an order (a request); the kitchen (another program) does the work you never see and sends out a dish (a response). You do not walk into the kitchen, and you do not need to know how the dish is cooked. You only need the menu and the promise that ordering item 12 always gives you item 12.

That "written down precisely" part is the whole point. Because the contract is fixed, the two sides can be built by different teams, in different languages, and can each change internally as long as the menu stays the same. A bank can rewrite its entire back end and, as long as its Get account balance API keeps returning a balance in the same shape, every app that reads it keeps working. The API is the stable seam between systems that are otherwise free to evolve.

How an API call works

Most APIs you will meet are web APIs: they work over the same HTTP that browsers use. A call has two halves — a request and a response — and a handful of parts you will see over and over:

• An endpoint — a URL that names the thing you want, e.g. https://api.example.com/v1/orders/482.
• A method (verb) — what you want to do to it: GET to read, POST to create, PUT/PATCH to update, DELETE to remove.
• Headers — metadata about the call, including who is asking (an API key or a token) and what format is expected.
• A body — for writes, the data you are sending, almost always as JSON.
• A status code — the response's one-glance verdict: 200 OK, 201 created, 400 your request was malformed, 401 you are not authenticated, 403 you are not allowed, 404 not found, 429 you are being rate-limited, 500 the server broke.

So "fetch order 482" is really GET /v1/orders/482 with an auth header, and the reply is 200 OK plus a JSON object describing the order. That is the entire shape of the vast majority of integrations — thousands of small, well-defined requests and responses. Learn to read that shape and most of the mystery disappears.

The main API styles

"API" is a category, not a single technology. A handful of styles dominate, and the differences decide how you build against them. This comparison is the one thing the narrower cluster articles do not give you:

For most new work the honest default is REST, reaching for GraphQL when a front end is starved by chatty endpoints, gRPC for performance-critical internal traffic, and webhooks whenever you would otherwise poll an API on a timer just to ask "has anything changed yet?"

Public, private and partner APIs

The same technology serves three very different audiences, and the audience — not the style — is usually what shapes the governance around it:

• Private (internal) APIs connect your own systems to each other. Most APIs in any organisation are these; they are never meant to leave the building.
• Partner APIs are shared with specific, contracted third parties — a logistics provider, a reseller, a bank. Access is deliberate and limited.
• Public (open) APIs are published for any developer to use, often with self-service sign-up and published rate limits. They are a product in their own right.

What production APIs need around them

A working API in isolation is a demo. A production API needs a supporting layer around it, and that layer is what API management is about. The essentials:

• Authentication and authorisation — proving who is calling and what they may do. Two mechanisms dominate: an API key (a static shared secret that identifies the calling application) and OAuth 2.0 (a token-based scheme that lets a user grant an app scoped, expiring access to their data without handing over their password). Keys are simple but coarse; OAuth 2.0 is the standard wherever a real user's data is involved.
• An API gateway — a single front door that handles auth, routing, rate limiting and logging so each service does not reinvent them.
• Versioning and a deprecation policy — how the API changes without breaking the apps that depend on it.
• Rate limits and quotas — protecting the back end from being overwhelmed, deliberately or accidentally.
• Documentation and a sandbox — because an undocumented API might as well not exist.
• Observability — metrics and logs, so you know which calls are failing before your callers tell you.

Why enterprise integration runs on APIs

APIs are the raw material of integration. When a system integrator connects your CRM to your finance system, or a systems-integration project stitches a dozen platforms into one workflow, the joins are almost all API calls — often orchestrated through an integration platform (iPaaS) that manages the connections, retries and data mapping between them.

This is why "do you have an API?" is now one of the first questions to ask of any enterprise software you buy. A product with a good API can be woven into the rest of your enterprise IT estate; one without a usable API becomes an island that people bridge by hand, with spreadsheets and copy-paste. The API is what makes a system a component rather than a silo.

APIs in Singapore

Singapore is an unusually good place to see APIs at national scale, because so much of its digital economy is built on shared, consent-driven ones:

Singpass and Myinfo. Singpass is Singapore's National Digital Identity. Through Myinfo, a resident can let a business retrieve government-verified personal details — name, address, income and more — with their consent, instead of re-keying and re-proving them.^[1] For businesses this collapses know-your-customer checks and onboarding forms from days to minutes, and it is all delivered as an API.

SGFinDex. The Singapore Financial Data Exchange, a joint initiative of the Monetary Authority of Singapore (MAS) and GovTech built on Singpass, lets an individual consolidate their financial data — deposits, cards, loans, insurance and investments from participating institutions, plus CPF balances, HDB loan and IRAS tax data from government agencies via Myinfo — with their consent.^[2] Its defining design choice is instructive: SGFinDex does not read or store anyone's financial information; it only transmits it, on consent, between the organisations the user authorises. It is an API network whose whole value is not holding the data.

APEX. Behind the scenes, GovTech runs the API Exchange (APEX) — a central platform for publishing, securing and consuming government APIs across government-to-government and government-to-business programmes, with access controlled through TechPass for public officers and vendors and Corppass for businesses.^[3] It is, in effect, the API gateway and marketplace for the public sector.

How to evaluate an API

Whether you are buying software or asking a vendor to integrate one, these are the questions that separate an API you can build on from one that will cost you later:

1. Is it documented, with a sandbox? Clear reference docs and a test environment are the single best predictor of a smooth integration.
2. How does it authenticate? API key, OAuth 2.0, or something bespoke — and does that match how sensitive the data is?
3. What is the versioning and deprecation policy? How much notice do you get before a breaking change, and how are versions supported in parallel?
4. What are the rate limits and the SLA? Both the ceiling on how much you can call, and the promise on uptime and latency.
5. Does it cover the operations you actually need, or only reads? Many "APIs" let you retrieve data but not write it back.
6. Is there support and a changelog? A living changelog and a real support channel signal an API that is maintained, not abandoned.

Building an integration?

The joins between your systems are only as good as the team that builds them. Compare Singapore system integrators and software partners who work with the APIs your platforms expose.

Browse System Integrators in Singapore

Frequently asked questions

Sources

1. Myinfo — Singapore Government Developer Portal (GovTech) — GovTech official checked 2026-09-01
2. Singapore Financial Data Exchange (SGFinDex) — Monetary Authority of Singapore — MAS official checked 2026-09-01
3. API Exchange (APEX) — Singapore Government Developer Portal (GovTech) — GovTech official checked 2026-09-01