APIs and systems integration
We add APIs to existing business systems and connect them to the other software an organisation runs, so data is entered once and a failed transfer is reported rather than silently lost.
What you probably want to know first
- Can you add an API to a system that was never designed to have one?
- Usually. The API is built over the existing business rules and database, so other systems get the same answers the users see. It is versioned, authenticated and documented, and it can be added without changing how the current screens work.
- We have integrations nobody understands. Where do you start?
- With a list: every transfer, what triggers it, what it sends where, and what happens when it fails. That alone often explains problems people have lived with for years. Fixes then go in order of the damage each failure causes.
- What access do you need?
- Read access to the source code of the systems involved, documentation or a test account for any third-party API, and a test environment where transfers can be tried without touching live data.
- What integrations have you built?
- On OpenIRIS: a public REST API with API keys and rate limiting for institutions to connect their own systems, sign-in through each institution's own identity provider, and transactional email. On Logtek's system: scheduled file transfers, message queues and application email. Our own tools connect to Microsoft 365, Xero, Azure DevOps and others through their APIs.
Who this page is for
This page is for IT and operations managers whose business systems need to share data: with each other, with partners, or with packaged software such as finance and HR systems. It applies whether you need an API added to a system you already run or a set of unreliable integrations put right.
Why integrations fail quietly
Most integration problems are not dramatic. A nightly transfer fails once a month, a record with an unexpected character is skipped, or a partner changes a field name. Each failure leaves two systems disagreeing, and the disagreement is found weeks later by someone reconciling figures by hand. The fix is rarely a new integration platform. It is a clear map of what moves where, rules for what happens when a transfer fails, and an alert that reaches a person.
How we approach it
We treat each integration as part of the system it belongs to: in source control, released through the same pipeline, tested against test systems and monitored in production. On OpenIRIS, the public API that institutions use to connect their own software is part of the same ASP.NET Core API that serves the application’s own screens, against the same database, so partners and users see the same data.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss an integration 0800 433 7990What we build
- REST APIs on existing systems
- Versioned, documented APIs over the business rules you already have, with API keys or sign-in, rate limits and audit logging.
- Single sign-on
- Users sign in with their organisation's own accounts, through its identity provider over SAML or OpenID Connect.
- System-to-system transfers
- Orders, invoices, bookings and reference data moved between systems, with retries and a record of every transfer.
- Files and queues
- Scheduled file transfers and message queues for systems that cannot call an API, made reliable and monitored.
- Email and notifications
- Application email through a delivery service, with bounces and failures tracked.
- Failures that get noticed
- A failed transfer raises an alert and can be replayed, rather than leaving two systems quietly disagreeing.
How an integration project runs
Map the data
Which records move, in which direction, which system is the source of truth for each field, and what happens on conflict.
Agree the failure rules
What retries automatically, what needs a person, and who is told.
Build against test systems
The integration is built and tested against test accounts or copies, never against live data first.
Run in parallel
Where possible, the new integration runs alongside the old process and the results are compared before the switch.
Monitor
Alerts on failures and a simple way to see what moved and when.
A good fit when
- Staff re-key the same data into two or more systems.
- An integration fails now and then and nobody notices until a customer does.
- Partners or customers want to connect to your system and there is no API.
- Users juggle separate logins for each internal system.
Probably not for you if
- Two off-the-shelf products that already have a supported connector between them; use the connector.
Questions we are asked
REST API or file transfer?
An API when both systems can use one, because errors come back immediately. Files when one side is an older system or a partner that only accepts files. Either can be made reliable; the difference is in how failures are detected.
Who owns the API once it is built?
You do, along with its code and documentation. It runs in your environment under your accounts.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.