API Integration Explained for Business Owners

An API is a defined way for one piece of software to ask another for something. Your accounting system publishes a list of things it will do on request — create an invoice, return a customer, list unpaid bills — and any authorised system can ask. It is a service counter with a published list of what can be requested and in what format.

The business consequence is simple: a system with a good API can be connected to your other systems without anyone re-typing. A system without one can usually still be connected, but through slower and more fragile methods.

What "we have an API" does not tell you

Vendors say it in sales meetings as though it settles the question. It does not, because APIs vary enormously in what they actually allow.

• It may be read-only. You can retrieve invoices but not create them — which rules out half the integrations people want.
• It may cover only part of the system. Customers and invoices exposed, but not the stock module you actually need.
• It may be rate-limited to a level below your volume, making a nightly sync of 10,000 records impossible.
• It may cost extra, or require an enterprise tier.
• It may be undocumented, which means discovery work billed at your expense.
• It may change without notice, which shifts an ongoing maintenance cost onto you.

The questions to ask before you buy

Ask these of any system you are considering, and get the answers in writing. They are cheap to ask now and expensive to discover later.

1. 01Is the API documentation publicly available? Send me the link. Public documentation is a strong signal that the API is a supported product rather than an afterthought.
2. 02Which objects can be read, and which can be created or updated? Name them specifically — customers, orders, stock, invoices, payments.
3. 03What are the rate limits, and what happens when they are exceeded?
4. 04Is API access included in our licence, or charged separately?
5. 05Is there a test or sandbox environment? Without one, all integration testing happens on live data.
6. 06How are breaking changes communicated, and how long is the notice period?
7. 07Are there webhooks for events, or is polling the only option?

If a system has no API

This is common with older Malaysian business software, and it is not a dead end. The usual options, roughly in order of preference:

• Direct database access — fast and complete, but bypasses the application’s business rules. We prefer read-only access, or writes only where the vendor sanctions them.
• Scheduled import and export files — many systems can produce a CSV on a schedule and consume one. Slower and batch-oriented, but reliable and low-risk.
• An adapter service — a small purpose-built component sitting beside the legacy system that exposes a modern API and translates to whatever the old system understands.
• Screen automation — driving the user interface programmatically. It works, it is genuinely fragile, and we treat it as a last resort with a plan to replace it.

Judging an integration proposal

You do not need to evaluate code, but you can evaluate whether the proposal has thought about the parts that matter.

• Does it name which system is authoritative for each piece of data?
• Does it include a field mapping document, or does it assume the fields will line up?
• Does it say what happens when the other system is unavailable?
• Does it explain how duplicate records are prevented on retry?
• Does it include logging and alerting, and say who gets alerted?
• Does it include a reconciliation step proving both sides agree?
• Does it say who maintains it when the vendor changes their API?

A proposal that covers all seven is likely to produce something you can rely on. One that covers only the happy path will work on the day it is delivered and become a support burden afterwards.

What integration work typically involves

For a single flow between two systems with reasonable APIs — orders from a storefront into an ERP, say — expect the effort to divide roughly into discovery and mapping, building, and testing, with mapping usually the largest share. The credentials, sandbox access and sample data need to come from you, and delays there are the most common cause of a slipped timeline.

Budget for ongoing maintenance too. Vendor APIs change, certificates expire, volumes grow. A modest support arrangement keeps an integration healthy for years; no arrangement at all means you find out it stopped when a customer tells you.