Organizations often accumulate software one operational need at a time: accounting software for finance, a separate stock system, a website for customer enquiries, spreadsheets for project delivery and another platform for maintenance. As the business grows, people become the integration layer—copying values between applications and reconciling inconsistent reports.
Replacing every system at once is rarely the safest first move. A better approach is to identify which systems should remain authoritative and connect them through dependable contracts.
1. Map the information journey
Select one process and trace it end to end. A purchasing flow might involve a requisition in an internal application, vendor approval in an ERP, delivery evidence on a mobile form and payment in accounting software. Identify the important states and handoffs.
For every data object—customer, supplier, invoice, machine, stock item, job card—answer:
- Which application is the system of record?
- Who may create, correct or archive it?
- What is its stable identifier?
- Which other systems need a copy or read-only view?
- How quickly must changes become visible?
- What happens when the network or one application is unavailable?
A diagram showing ownership and flow is more valuable than a list of vendor logos.
2. Choose integration methods deliberately
Scroll horizontally if needed to read all columns.
| Method | Suitable for | Main limitations |
|---|---|---|
| REST/HTTP API | Controlled requests, queries and updates | Authentication, rate limits, versioning and failure handling |
| Webhooks | Notifications when something changes | Retries, message authenticity, delivery ordering |
| File import/export | Scheduled batches, legacy and low-connectivity environments | Delays, schema drift, duplicate files and reconciliation |
| Database views or replication | Authorized access to structured data | Tight coupling, schema changes, privileged access risk |
| Message broker or event stream | Many independent consumers or asynchronous activity | Operational complexity, delivery and ordering semantics |
Use the least complex approach that satisfies the actual requirements. A daily CSV import can be perfectly acceptable for a small operation; a highly distributed event platform is unnecessary if there is no real-time need.
3. Specify the contract, not just the endpoint
An integration contract should define fields, units, mandatory identifiers, allowed values, timestamps, versioning, authentication, authorization and errors. It should also define idempotency—what happens if the same request is delivered twice.
For example, if a source sends invoice INV-1024 twice due to a timeout, the receiving system must not automatically create duplicate invoices. The implementation may use a stable external event ID, request ID or source-system key according to the business rules.
The OpenAPI Specification supports machine- and human-readable descriptions of HTTP APIs. Such specifications help teams define and review contracts, but good integration also needs behavior and operational guarantees that documentation alone cannot supply.
4. Design for partial failure
Consider a remote branch that loses internet access while capturing delivery confirmations. A well-designed application can hold authorized records locally, identify when each record was created, and synchronize when connectivity returns. It should not silently discard failed submissions or claim synchronization succeeded before a server acknowledges receipt.
Define retry policy, backoff, deduplication, ordering, conflict resolution and dead-letter or exception handling. Use clear operational status such as captured locally, queued, accepted, rejected or requires correction.
For financial and other sensitive transactions, confirm whether the business allows offline capture at all and what authorization limits apply.
5. Separate read access from command authority
Industrial environments need an especially careful boundary. Reading approved production or historian data does not imply permission to change equipment settings. Integrations into operational technology must be scoped, assessed and configured for their specific reliability and safety context.
Similarly, a reporting application should not casually gain unrestricted access to update the accounting database. Least privilege reduces both accidental mistakes and security exposure.
6. Build reconciliation into normal operations
Integration success is not merely “the API returned 200.” Reconciliation asks whether source and destination agree about what was delivered and accepted.
Track total records exported, received, accepted, rejected, replayed and corrected over a defined interval. Keep raw payload references, response codes, schema versions and the identity of any correction. Alert when expected feeds stop arriving; stale information can look deceptively normal on a dashboard.
7. Plan changes and vendor exit
Integrations degrade when source applications change field names, identifiers or permissions. Assign ownership, monitor contract drift, use versioned mappings and test changes against representative samples. Document how to reconnect or migrate without losing historical records.
Implementation checklist
- Map source systems and business owners.
- Identify one system of record per shared entity.
- Agree on identifiers, time zones, units and schema versions.
- Define authentication, permissions and credential rotation.
- Implement validation, replay and deduplication.
- Make offline and failure behavior explicit.
- Reconcile source and destination totals.
- Monitor freshness, errors and processing latency.
- Document support ownership and exit paths.
Frequently asked questions
What if our existing software has no API? Evaluate authorized exports, scheduled files, vendor-supported database views or carefully designed complementary workflows. Avoid brittle screen-scraping if a stable supported interface exists.
Can an integration be real-time? Yes, when systems and operational needs support it. Real-time delivery adds complexity; do not pay for it without a business requirement.
Is middleware always necessary? No. A small number of well-defined connections may not need a separate integration platform. Shared observability becomes more important as integrations multiply.
Who owns cross-system errors? Decide before launch. Every interface needs an accountable operational owner and a process for correcting records without erasing the history.
Related reading
See Excel vs ERP vs Custom Software, APIs Explained for Business Owners and Offline-First Software in Africa.
