CarLicence
CarLicence, a South African startup, provides white-label licence disc renewal (LDR) infrastructure that businesses, insurers, and financial platforms integrate into their own websites, mobile…
View Case Study →Connecting the systems you already run — and the APIs you offer to others
Your systems should talk to each other. Usually they do not.
ERPs, CRMs, marketplaces, payment providers, government back-offices, a vendor's middleware, a spreadsheet that became a system. Most businesses run on a patchwork that was never designed to work together. We build the integration layer that connects it properly, and the APIs you expose when other companies need to connect to you.
Manual bridges do not scale, and silent ones are worse.
Data gets re-entered by hand. Two systems each hold a version of the truth and nobody can explain the difference. A script written years ago quietly breaks every few months, and the person who wrote it has left. The failure mode that costs the most is not the integration that stops; it is the one that keeps running and drops records nobody notices until an auditor or a customer does.
Integration is usually treated as an afterthought: bolted on late, undocumented, abandoned the moment it works once. We treat it as engineering, with a data model, error handling, an audit trail and an owner, because that is what it is.
What we build.
Integrations between the systems you run, and the interfaces you offer to partners. Both with the same discipline: mapped explicitly, logged completely, and safe to change.
- ERP and CRM connectivity: Sage 100, SAP via existing middleware, and the in-house systems that surround them, extended with portals and mobile apps that read and write ERP data without manual re-entry
- Marketplace, inventory and finance platforms (Zoho, Sellerboard, Amazon) consolidated into one reporting and decision layer, with SKU and identifier mapping that reconciles what each system calls the same product
- Reconciliation as a feature: scheduled imports that compare systems and surface discrepancies as exceptions to review, instead of differences absorbed into a spreadsheet
- Format bridging where a partner dictates the data model, such as converting quotations from a business system into a large provider's mandated XML procurement format
- Public-sector and multi-authority back-ends unified behind one API, so a consumer app sees one consistent interface however many sources sit behind it
- APIs you expose to others: design, versioning, documentation and sandboxes, so a partner can integrate against you in hours rather than weeks
- Secure transport and field resilience: encrypted tunnels, retries and a visible failed-upload queue, because unreliable connectivity is a normal operating condition, not an edge case
- Monitoring, logging and an import audit trail that answers what was sent, when, to which record and whether it completed, so failures surface immediately instead of months later
Why exbisoft.
The missing layer between two systems that both work.
A garment manufacturer selling on Amazon ran Zoho Inventory and Sellerboard, and neither could answer management's questions. We built the platform between them: audited imports, SKU mapping across four identifier schemes, automated reconciliation, landed cost per unit and a replenishment workbench that writes draft purchase orders back to Zoho. Neither system was replaced.
ERP data where the work happens.
For a German machinery manufacturer we extended Sage 100 with a purchasing portal its international vendors use to confirm orders and log shipments; the ERP stays current without anyone re-typing. For a software vendor we kept a warehouse app talking to the same Sage 100 data layer while moving it from Windows CE to Android.
Built to survive change.
Systems get replaced, upgraded and re-versioned. We map explicitly, keep the mapping reviewable, and separate transport from business rules, so when the partner changes its format or the ERP is upgraded, the change is one layer, not a rewrite. The D!VE XML converter we built has followed the provider's format through several revisions.
Also the API side of the table.
A licence-renewal platform we built and run exposes a real-time API that partners embed in websites, apps, point-of-sale systems and ATMs. Designing an interface others depend on is a different job from consuming one, and we have done both.
Documented, not tribal knowledge.
Every integration ships with documentation a future developer can actually use, including one who never met us, plus logs that let an administrator retry a failed record without calling anyone.
Systems that should be talking but aren't?
Tell us what needs to connect, what each side calls the data, and what happens today when a transfer fails. We will tell you honestly how much work that actually is, and where the risk sits.
Start a conversation