How can two business software systems exchange information through an API?
An API is a defined way for software to request information or actions from another system. A business integration needs supported access, agreed data fields, permissions and rules for failures. Start with one complete workflow, prove it using test records and give staff a way to see and correct exceptions.
The key idea
“The systems have APIs” is the start of the investigation. The important question is whether they support the records and actions your workflow needs.
Follow one order from one system to the next
Consider an illustrative wholesaler: a customer orders through a website, warehouse staff prepare the goods and finance records the sale. The proposed connection sends order details to the operational system and brings an agreed status back. Write the record that crosses the boundary: order reference, product identifiers, quantities, delivery information and payment state.
Decide which actions remain with people. Staff may still need to approve credit, substitute an item or check unusual instructions. Connecting systems should remove repeated entry without bypassing decisions the business actually requires. Specify what the customer sees at each stage and which employee handles an exception.
Check both sides of the connection
Ask each vendor for current API documentation, supported actions, access terms and a test environment. Can the receiving system create an order, update one or only read information? Does access depend on a licence or vendor approval? MDN explains web requests and responses; your supplier should translate the relevant interface into business capabilities.
Make a small capability matrix rather than accepting “fully integrated.” For each record, note the source, destination, fields and permitted action. Confirm versions and limits with the vendor. If an interface lacks a required action, include the workaround and its operational cost in the proposal instead of leaving it to emerge during delivery.
In practice · illustrative example
Rehearse a repeated update before connecting live orders
Imagine a completed order being sent from the store to an accounting system. A delayed acknowledgement may lead the sender to try again. The business should still be able to identify one intended transaction. Give the systems an agreed reference and define how repeated messages are recognised, instead of assuming every received message represents new work.
This is not only a developer test. Ask staff to explain what they see when an update is pending, repeated or rejected. Keep the correction route visible and avoid silent manual edits that destroy the shared reference. The connection is useful when its normal results and its exceptions both remain understandable.
A repeated message should not become unexplained duplicate work
-
Identify the event
The sender supplies the agreed transaction or event reference.
-
Check prior handling
The receiver can recognise whether the intended work was already handled.
-
Apply or investigate
The agreed rule handles the update or records an exception.
-
Explain the outcome
Staff can trace the result without inventing a second transaction.
Agree what the information means
A status called “complete” may mean paid on the website and dispatched in the warehouse. Map these meanings before connecting the systems. Match stable identifiers, date and timezone handling, units and amount precision. Keep the original source reference available so the same record can be traced afterward.
Decide who owns fields and what happens when staff edit them in both systems. For example, changing a delivery address after dispatch may require a person to approve the correction. Arabic and English labels should refer to the same underlying record. Include a clear response for missing or invalid data; silently accepting a half-complete order merely moves the problem.
Describe what happens when the first attempt fails
A connection can request information when needed, check periodically or receive an event notification where supported. Choose around the required timeliness and the interfaces available. Regardless of the mechanism, plan for an unavailable system, delayed result and repeated request.
Ask how a retry avoids duplicate orders or invoices. Keep an event or transaction reference and show staff whether transfer is pending, successful or failed. Establish safe retry and reconciliation procedures. An error should not disappear into a developer’s log while the employee assumes the order transferred. Agree who receives alerts and when staff use a temporary manual process.
Give the connection only the access it needs
Define the records the integration can read or change, and keep credentials out of public browser code and shared documents. OWASP identifies risks including broken authorisation and unsafe API consumption. Ask the technical team to explain how access is restricted and how incoming information is validated.
Record who can revoke or replace the integration credentials. Share only the customer information required by the workflow, and identify each system that receives it. A supplier should not need unrestricted administrator access forever merely because it built the first connection. Include staff access and vendor changes in the handover discussion.
Test a complete transaction and its exceptions
Use a small test set: one normal order, one unknown product, a duplicate transfer, a changed address and an outage. Have staff locate the records on both sides and explain the result. Check that the connection reports a failure honestly and does not mark incomplete work as done.
Document the configuration, supported interface version, important field mappings and operating instructions. Agree support responsibility when a vendor changes its interface. A first successful demonstration is a useful milestone, but acceptance should include recoverability and handover. The goal is a process your team can trust on an ordinary busy day, when nobody has time to compare two screens line by line.
A worksheet for your team
An exception test for your integration supplier
Ask the team to demonstrate these cases in an agreed test environment, using non-production records.
| Decision | Evidence to request | What to do next |
|---|---|---|
| Repeated delivery | The same test update supplied twice. | Check that staff can recognise the intended single outcome. |
| Rejected record | An update missing a required business field. | Keep the error and correction owner visible. |
| Delayed response | A request whose acknowledgement arrives late. | Agree investigation and retry behaviour before launch. |
Keep these tests with the handover documents. They provide a useful regression check when either connected system changes.
A clear API integration brief
- One complete workflow and actions that stay with staff.
- Confirmed API capabilities and access on both systems.
- Field ownership, identifiers and status mappings.
- Duplicate prevention, alerts, retries and reconciliation.
- Restricted credentials, test results and handover instructions.
Frequently asked questions
Is an API the same as a ready-made integration?
No. It provides an interface, while an integration applies business rules between systems. Check whether a supported connector already covers the workflow and what additional work it requires.
Does API integration always happen instantly?
No. Timing depends on the mechanism, system availability and vendor limits. Agree what delay is acceptable and how staff can see information still waiting to transfer.
What if a system has no usable API?
Ask about supported exports, connectors or vendor-assisted options. Compare the manual work and limitations. Do not assume an unsupported workaround will remain reliable after software changes.
Sources and further reading
These primary sources support the specific company or platform information in this guide. Provider descriptions do not imply an endorsement by the source.
- MDN: HTTP requests and responses
- OWASP: API security risks
- Stripe documentation: handling duplicate webhook events
Sources checked:
Bring a workflow, not just two software names
Tell GateGold which records move between your systems and what staff do with them. We can discuss a supported integration and acceptance checks.
