A Guide to System Integration and API Development: Requirements, Risks, and Acceptance
“We want orders to flow into the fulfillment system automatically.” “Members should be the same on the website and in store.” “Can customers check their order status in LINE?” (LINE is the messaging app almost every consumer in Taiwan uses, so it doubles as a customer-service and notification channel.) These requests sound unrelated. Underneath, they are all the same thing: system integration.
Integration projects have one unusual property: the difficulty is not on your side. The technology is usually not complex, but because you are dealing with somebody else’s system, the sources of schedule risk are completely different from ordinary development.
Understanding an API in plain terms
Think of an API as a service counter between two systems. You do not walk into somebody else’s server room looking for data; you submit a request at the counter in the format they specify, and the counter hands the data over or carries out an action for you, such as creating an order or checking a stock level.
The analogy extends into a few practical points:
- Counters have a defined scope. A provider willing to let you read data is not necessarily willing to let you write it. Many integrations stall not because something is impossible but because that particular window was never opened.
- Counters have queueing rules. Most services limit how often you may call them, so large data synchronizations have to be batched.
- Counters have off days. Maintenance windows, version changes, expiring certificates — your system has to absorb these rather than fall over.
Understanding those three points is what lets you ask the right questions when you discuss an integration with a vendor.
Common types of integration requirement
Order flow. Pushing order data into a fulfillment, warehouse, or ERP system and returning shipping status and tracking numbers. The value here is the most immediate, because what it replaces is copy-and-paste work that happens every single day.
Stock synchronization. Keeping inventory consistent across channels when you sell in more than one place. The difficulty is in the synchronization frequency and the rules for handling oversells — true real-time is expensive, so most cases settle on a balance between acceptable delay and a safety buffer.
Members and loyalty points. Letting the website, the store, and the app see the same customer. The hard part is usually not technical: it is deciding which system holds the master record, and how duplicate legacy records get merged.
Payments and invoicing. Payment, refunds, invoice issuance and voiding. Handling the exception cases matters more than the happy path; the detail is in the e-commerce development guide.
CRM and marketing tools. Feeding customer behavior and contact lists into customer relationship management or marketing automation platforms. Pay particular attention to the scope and stated purpose of the personal data being collected, and refer to the latest guidance from the relevant authorities.
LINE and other messaging platforms. Order notifications, account linking, handing conversations to a human agent. Note that the features and policies of these platforms get revised, so treat the official documentation as authoritative on what is currently available.
Apps and back-end systems. An app communicates with its back end through an API by definition, so an app project almost always contains interface design work. The related cost structure is in the complete guide to app development costs.
Three ways to connect, in plain terms
They all get called “integration”, but there are three distinct approaches, and their costs and suitable situations differ considerably.
Direct calls. Ask the question the moment you need the answer — checking stock while a customer is at checkout, for example. The advantage is the freshest possible data; the drawback is that when the other system slows down your screen slows with it, and a high call volume runs into rate limits.
Scheduled batches. Move a set of records at a fixed time, such as synchronizing product data overnight. The advantage is stability and the lightest load on both sides; the drawback is a built-in delay, which makes it unsuitable for fields that influence a transaction decision.
Event notifications. The other system tells you the moment something changes, such as pushing a result as soon as payment completes. The advantage is immediacy without wasting calls; the drawback is that notifications may duplicate or go missing, so your system has to handle receiving the same message twice and needs a way to catch up on anything that was lost.
In practice one project often uses all three: event notifications with a catch-up mechanism for transactions, direct calls for lookups, and batches for bulk data. When discussing requirements, asking a vendor “which approach are you planning here, and why” reveals far more about whether they have thought it through than asking how long it will take.
Why integration projects habitually overrun
One: the documentation does not match the actual behavior. This is the most common situation by far. The documentation says a field is mandatory; in reality it accepts blanks. The documentation says a number is returned; in reality it is text. There is only one remedy: run real tests before quoting and scheduling, using a genuine test account, to confirm the formats and error messages really are what they claim to be.
Two: the data definitions do not line up. The same customer carries different identifiers on each side, product specifications use different units, dates may or may not carry a time zone, amounts may or may not include tax. These look trivial and consume more time than anything else in an integration — and when they are wrong, the result is an accounting problem.
Three: permissions and security procedures involve waiting. Requesting production credentials, allowlisting addresses, passing a security review — all of these depend on the other party’s contact. None of them compresses by adding people.
Four: the other side releases new versions too. After an integration goes live, an update on the other system can break a connection that worked perfectly well. This is a long-term cost, not a one-off task.
Five: nobody is defining the rules. “What happens when an order is canceled but has already shipped?” is a business decision, not an engineering question. With nobody to make the call, development simply stops there.
The audit checklist to complete beforehand
Putting the following together before asking for a quote dramatically reduces the chance of a bad estimate.
System inventory. Every system to be connected: its name, its version, whether it is self-hosted or a cloud service, who maintains it, and whether there is a current point of contact.
Data flows. For each record: where it comes from, where it goes, whether the flow is one-way or two-way, and which side holds the master. Drawing this as a single diagram beats ten pages of description.
Frequency and volume. Real-time, hourly, or once a day? Roughly how many records per day, and how many at peak?
The current manual process. Who handles it by hand today, in what file format, and how long it takes each day. This doubles as the justification for the requirement and the baseline for measuring the benefit afterwards.
Documentation and test environments. Whether the other party has technical documentation, whether a test environment exists, and how long access takes to arrange.
Exception rules. Returns, cancellations, amendments, partial shipments, stockouts. How these are handled is a decision for your side to make.
Named owners. Who the technical contact is on the other system, and roughly how quickly they respond. This item frequently sets the pace of the entire project.
This audit does not have to be written by technical staff. Every question in it is a business question: where does the data come from now, who handles it, how long does it take, and who is responsible when it goes wrong. Compiled by the colleagues who know the operation best, it will be far more accurate than anything an outside vendor can infer, and it lets a quote rest on real conditions rather than assumptions.
Once the audit is done, there is one more step: put the items in priority order. Not every integration is worth building. Three criteria help — how many hours of manual work this connection saves each month, how serious the consequences are when it fails, and how cooperative the other system’s owner is. Pushing back the items with low cooperation and unclear benefit is usually more pragmatic than insisting on doing everything at once.
What acceptance testing and monitoring should look for
Acceptance for an integration cannot stop at “does it work when everything is normal”. It should cover at least the following.
Exception testing. The other side returns an error, times out, receives the same record twice, or the transfer is cut off midway. Whether the system should retry, log, or escalate to a human has to be defined behavior.
Duplicate protection. The same order submitted twice should not become two orders. This matters especially for payments and stock.
Queryable logs. Every transfer should leave behind a timestamp, its contents, and its result, so that when something goes wrong you can find out who did what at which step.
Failures must reach someone. The dangerous case is not failure but silent failure. Set up failure notifications and name the person receiving them at launch, not later.
Regular reconciliation. Compare volumes and amounts on both sides on a schedule. However stable a system is, differences accumulate over a long enough run, and the point is to catch them early.
Responsibilities after launch belong in the maintenance contract, including who handles the other party’s version changes and how response times are counted; that is covered in what website maintenance actually covers.
When to bring in a consultant before starting development
If your situation is “we know a lot of things need connecting, but not which one to start with”, the first step is not to hire someone to write code.
Integration requirements typically span several systems and several departments, and a single audit of the current state with an agreed priority order costs less than attempting everything at once. NETVANA’s technical consulting services — covering architecture review, technology selection assessment, and CTO-as-a-Service — deliver a technical assessment report, an architecture recommendation document, and a prioritized roadmap, precisely so that what to do first, what to do later, and what turns out not to be needed at all are clear before work begins. For the trade-off between building an internal team and bringing in outside help, see outsourcing versus an in-house team.
If what you need to connect to is an old system nobody dares touch, the problem sits one level higher; the approach is in the legacy system modernization guide.
Whether a system integration succeeds is largely settled before any work starts: whether the data definitions are aligned, whether the other party’s contact actually responds, and whether somebody has ruled on the exception cases. The code only writes those decisions down.
If you have several systems you would like to connect and are not yet sure where to begin, talk to NETVANA about your integration requirements. We start by auditing the current state and the data flows before discussing solutions; software services are quoted after a consultation, and the scope of each is set out in the software services overview.
Further reading: for integration in an e-commerce context, see the e-commerce development guide. For strategies on replacing aging systems, see the legacy system modernization guide. And for the questions to ask when evaluating vendors, see how to choose a software development company. For what to build once your data is connected, see Adding AI Features to Your Business; and for the admin system that consumes your integrated data, see A Guide to Building Internal Admin Systems; and for defining defect severity and acceptance for integration work, see How Software Acceptance Works. For a concrete external API integration worth studying, see Integrating the Taiwan E-Invoice System; and for the asynchronous callbacks that break most integrations, see Logistics Integration in Taiwan; and for identity integrations and their own authorization flow, see Social Login and SSO. Routing approvals into HR and finance systems raises the same integration risks; see Electronic Forms and Approval Workflow Systems.
