API Integration
Your systems talk to each other instead of somebody retyping between them.
What is API integration?
API integration connects two or more software systems so data passes between them automatically, with agreed rules about what happens when a system is unavailable, a record is rejected or the same message arrives twice.
Every business ends up with systems that do not talk. Sales sits in one, accounts in another, stock in a third, and somebody bridges the gap by exporting a spreadsheet on Friday.
That person is the integration. They are slow, they make mistakes, and the business stops when they take leave.
Connecting the systems properly is well understood work. The part that separates a good integration from one you will regret is not the connection, it is what happens when something fails.
Where the build time actually goes
Duara builds integrations from Nairobi, including M-Pesa, KRA eTIMS, banking and the usual business platforms, plus custom APIs where a system has no standard connector.
We spend most of the build on failure handling, which is not what anybody wants to pay for. An integration that only works when both systems are up will silently drop records the first time one is not, and you will find out weeks later when the numbers do not agree.
Who this is for
- Data is exported and re-imported by hand
- The same record is typed into two systems
- A spreadsheet bridges two platforms
- Your systems disagree and nobody knows which is right
Industries we serve
- Retail and e-commerce
- Financial services
- Logistics
- Healthcare providers
- Manufacturing
- Professional services
Problems this solves
These are integration gaps being filled by a person, which works until it does not.
- A person is the integration. Somebody exports from one system and imports into another, which is slow, error prone and stops when they are away.
- The same record entered twice. Double entry guarantees the two systems will eventually disagree, and finding out which is right takes longer than the entry did.
- Spreadsheets as bridges. A weekly export means the second system is always days behind the first.
- Failures nobody notices. Where an integration already exists, dropped records often go unnoticed until a reconciliation fails weeks later.
What we deliver
Direct connections between your systems with agreed field mapping, retry handling when a system is down, duplicate protection, and alerting when something genuinely needs a person.
Direct connections between your systems
Agreed mapping of which field means what
Retry handling when a system is unavailable
Protection against duplicate records
Alerting when something needs a person
Documentation your own developers can maintain
Features
- Failure handling first. Retries, queues and alerts are built before the happy path, because that is what determines whether you can trust it.
- Duplicate protection. The same message arriving twice does not create two records, which is a common and expensive integration bug.
- Field mapping agreed with you. What each field means is settled explicitly, since most integration disputes are definitional rather than technical.
- Kenyan systems supported. M-Pesa, KRA eTIMS and local bank APIs, alongside the international platforms.
- Documented for handover. Written so your developers can maintain it, rather than leaving you dependent on us.
Benefits
- The manual bridge disappears. The export and re-import job stops existing, along with the risk that it stops when one person is away.
- Systems stop disagreeing. One source of truth per field removes the argument about which system is right.
- Data arrives when it happens. Downstream systems stop being days behind because they no longer wait for a weekly export.
- Failures become visible. You find out about a dropped record when it happens rather than at the next reconciliation.
Technologies we use
- REST and webhook integration. Connecting modern platforms through their published interfaces.
- Queuing and retry. Holding messages when a system is down and delivering them when it returns.
- Idempotency handling. Ensuring a repeated message does not create a duplicate record.
- Field mapping and transformation. Converting formats and definitions between systems that structure the same thing differently.
- Monitoring and alerting. Detecting failures and telling somebody, rather than failing silently.
Most integrations that go wrong were built assuming both systems are always available. They are not, and designing for that is the actual work.
How the process works, step by step
A typical integration takes two to five weeks, depending mostly on how well documented the systems at each end are.
-
Step 1
Free systems review
We establish what needs to connect, which system owns each field, and what interfaces actually exist.
-
Step 2
Mapping agreed
Field by field mapping is settled in writing, which is where definitional differences between systems surface.
-
Step 3
Built with failure handling
Retries, duplicate protection and alerting are built alongside the connection rather than after it.
-
Step 4
Tested against real failure
We take systems offline deliberately during testing, because that is the condition that matters.
-
Step 5
Handover with documentation
Your developers receive documentation sufficient to maintain and extend it.
Quality assurance and how we work
The commitments attached to moving your data between systems.
- Failure handling is built first. An integration that only works when both systems are up will silently drop records, and you will discover it weeks later.
- We test by breaking things. Systems are taken offline deliberately during testing, since behaviour under failure is the only part worth proving.
- One system owns each field. We insist on deciding which side is authoritative, because two way sync without a rule produces conflicts nobody can resolve.
- You get documentation. Written so your own developers can maintain it. An integration only we understand is a liability we will not leave you with.
- We say when an integration is a bad idea. Where a platform interface is too limited to do this reliably, we tell you rather than building something fragile.
Frequently asked questions about API integration
Can you connect any two systems?
Where both publish a usable interface, yes. Where one does not, we say so at the review rather than building something fragile around it.
Do you integrate M-Pesa?
Yes, including paybill and till, which is among the most common requests we get.
Can you connect to KRA eTIMS?
Yes, and this is increasingly requested as invoicing requirements tighten.
What happens if one system goes down?
Messages queue and deliver when it returns. This is designed first, because an integration without it drops records silently.
How do you prevent duplicate records?
Through idempotency handling, so the same message arriving twice does not create two records. It is a common and expensive bug.
What if the two systems disagree?
One system owns each field. We insist on deciding that, because two way sync without a rule produces conflicts nobody can resolve.
Can you do two way synchronisation?
Yes, with clear ownership rules per field. Without those rules it eventually corrupts both sides.
How long does an integration take?
Two to five weeks, driven mostly by how well documented the systems at each end are.
Will we be locked into you?
No. You get documentation sufficient for your own developers to maintain and extend it. An integration only we understand is a liability.
How do we know it is running?
Monitoring alerts a named person on failure. Silent failure is the main thing this design exists to prevent.
Can it handle high volumes?
Yes, with queuing sized to your throughput, which we establish from your actual figures rather than assuming.
What if a platform changes its API?
Versioned interfaces usually give notice. We build so a change is a contained fix, and monitoring catches it either way.
Do you work with legacy systems?
Often, through database level or file based integration where no API exists, though we are explicit about the trade offs.
Can you integrate our custom software?
Yes, and where it has no interface we can build one, which is sometimes the cheaper path overall.
What about data that fails validation?
It goes to an exception queue with the reason, rather than being dropped or forced through.
Does data pass through your systems?
No. Integrations run in your infrastructure or between the platforms directly. We do not hold your data.
Can you integrate with our bank?
Where the bank offers an interface, yes. Coverage varies between Kenyan banks and we check before quoting.
Will this slow our systems down?
Properly built integrations run asynchronously, so neither system waits for the other.
Is our data secure in transit?
Yes, encrypted in transit, with credentials held in a secrets store rather than in configuration files.
What does an integration cost?
The number of connections and the state of the interfaces determine it, quoted after the systems review.
Glossary of terms
Integration terms in plain language.
- API
- A published interface that lets one system request data or actions from another.
- Webhook
- A message a system sends automatically when something happens, rather than waiting to be asked.
- Idempotency
- The property that receiving the same message twice has the same effect as receiving it once.
- Field mapping
- The agreed correspondence between a field in one system and a field in another.
- Retry queue
- Where messages wait when the receiving system is unavailable.
- Source of truth
- The system whose version of a field is authoritative when two disagree.
Related services in Automation
Talk to us about API integration
Name the export somebody does every week. That is usually the integration worth building first.
Start your project