Technology · Integrations
System integration and automated data exchange.
We connect systems, define the source of truth for each field and make failures visible rather than silent.
When clients usually bring us in
- the existing system no longer keeps up
- the work happens in spreadsheets
- data is duplicated across systems
- you need a new application
- you want to modernise an old system
- you're building a new digital product
You don't always have to build from scratch
If the existing system can be properly modernised or connected to others, that's usually faster and cheaper than a new application. We start by looking at what's worth keeping.
What this means for you
- Fewer spreadsheets and manual status updates.
- Less duplicated data across systems.
- One view of the process for management and the team.
- A system that grows with the company.
- Less dependence on the one person who knows how it works.
Problem → solution
What we connect
- ERP
- CRM
- e-commerce
- payment systems
- accounting
- document systems
- Google Workspace and Microsoft
- registries and external APIs
- logistics and warehouse
How we make it reliable
Source of truth
For every field we define which system wins and what happens on conflict.
Retries
Queues and retries without duplicating records - nothing is lost.
Monitoring
Alerts on failure, a transfer history and manual re-run.
When an integration is actually finished
A production-grade integration is not finished the first time data moves from system A to system B. Validation, error handling, retry logic, timeouts, observability and ownership of failed transactions all have to be designed as part of the integration.
That is why we treat integrations as a workstream in their own right, with their own requirements, test scenarios and acceptance criteria - not as the last line item on a feature list.
Integration patterns and when each one fits
| Pattern | When it fits | What to watch |
|---|---|---|
| REST API | synchronous exchange where the user needs an answer immediately | timeouts, error handling, rate limits |
| SOAP | older systems and registries that expose nothing else | schema, versioning, more elaborate fault handling |
| Webhook | the external system announces an event as soon as it happens | authenticity checks, duplicate messages, retries |
| File exchange | large volumes, systems without an API | file structure, encoding, partial files, locking |
| Scheduled import | data does not change often | the execution window, transfer size, handling delays |
| Batch processing | large processing runs outside business hours | runtime, restart, partial success |
| Asynchronous processing | processing takes time or the target is not always available | queueing, retries, messages that cannot be processed |
When a system must not wait for an immediate answer, the transfer runs asynchronously: the request is queued, processed in the background, retried under an agreed rule, and messages that still cannot be processed are set aside where they remain visible and can be re-run. The specific technology is chosen to fit the client's environment.
Authentication, authorisation and identity between systems
Every connection needs an answer to three questions: who is calling, what they may do and how that is verified. We choose the mechanism based on what the external system supports and on the client's security requirements.
- OAuth and short-lived tokens
- API keys with permissions separated by purpose
- single sign-on for user-facing scenarios
- server certificates and IP restrictions where required
- separate credentials for test and production
- secrets kept out of the source code, with rotation
Validation, failures and retries
An integration that goes quiet on failure is more dangerous than one that is clearly broken: the data looks right when it is not. So we define up front what a valid record is, what happens to an invalid one, when a transfer is retried and who is told if the retries do not succeed.
Who owns a failed record
For every integration we agree who on the client side handles the records that did not go through. Without that, in practice nobody does.
- validating input before anything is written to the target system
- transformations between different representations of the same field
- retries that do not create duplicate records
- timeouts and behaviour when the external system does not answer
- a separate store for records that could not be processed
- alerting the responsible person on failure, not at the first complaint
- the ability to re-run a single transfer by hand
Monitoring, reconciliation and audit trail
After go-live it has to be possible to answer “did everything get through today?” without guessing. We keep a transfer history, the state of each record and the reason for a failure, and make it possible to compare the source and the target.
- a transfer history with source, time and outcome
- alerts on stalls and on unusual transfer volumes
- periodic reconciliation between the two systems
- an audit trail for changes to important records
- interface versioning and a plan for moving to a new version
Data migration is a workstream of its own
In complex systems, data migration is not a database import. It is a sequence of steps in which you first establish what is actually in the sources, and only then what of it belongs in the new system.
Source inventory
which systems, which tables, who owns the data and when it was last maintained
Mapping
which source field maps to which target field, and what to do when there is no match
Cleaning
duplicates, missing fields, inconsistent formats and broken identifiers
Transformation
aligning formats, code lists and units
Dry run
a migration into the test environment, reviewed with the users
Validation
comparing record counts, totals and sample cases
Reconciliation
resolving differences and deciding on records that cannot be migrated
Final migration
the cutover, with an agreed window and a fallback plan
Data quality and the source of truth
An integration does not fix bad data - it distributes it faster. If the ERP, the CRM and the portal use different identifiers for the same customer, connecting them does not solve the problem; it makes it visible in all three.
So for every important field we define which system is the source of truth, who may change it and what happens when values conflict.
- missing records and incomplete fields
- duplicate records for the same customer or product
- inconsistent dates, addresses and tax numbers
- broken links between records
- stale data nobody maintains
- unclear ownership of the data inside the organisation
A typical scenario
The example below is not a reference; it illustrates the type of problem this work solves.
When a request is submitted, the portal has to check the customer in the CRM, pull contract data from the ERP, store the attached document in the document system and return a processing status to the user. If the ERP is unavailable at that moment, the request must still be created, the user must get a clear answer, the transfer must retry automatically, and if it ultimately fails, the responsible person must be alerted.
Who works on an integration workstream
The team is sized to the scope. A small connection needs an architect and a backend developer; a larger exchange between several systems has separate roles.
- a solution architect for the exchange design and the source of truth
- a business analyst for rules, exceptions and mappings
- a backend developer to build the interfaces
- a data specialist for migration and reconciliation
- a QA engineer for API testing and failure scenarios
- a DevOps engineer for environments, monitoring and alerts
What we need from the client
- a list of the systems to be connected and their versions
- interface documentation or access to the system vendor
- access to the external system's test environment
- sample data, including the messy kind
- an owner for the rules and the exceptions
- an agreement on who handles failed transfers
What the client receives
- a working integration in production
- documentation of the interfaces, mappings and rules
- test scenarios, including failure scenarios
- a view of the transfer history and record states
- alerts and an agreed procedure when something fails
- a migration and reconciliation report where migration was in scope
How we build the system
Architecture
We define the data model, modules and system boundaries before development, so later growth doesn't require a rewrite.
UX/UI
You approve the user journeys and a prototype of the key screens before any feature is written.
Frontend and backend
The interface and the server side are built to one standard: readable code covered by automated tests.
Integrations
Connections to ERP, CRM, document systems and registries, with logging and retries.
Data
Migration, cleanup and data quality rules, so the new system doesn't inherit the old errors.
Security, quality, rollout
Security
Authentication and permissions, encryption in transit and at rest, an audit trail and a review before go-live.
Testing
Automated tests, regression and acceptance testing against your criteria, not ours.
Deployment
Separate environments, phased release and the ability to roll back within minutes.
Handover
Code, access, documentation and team training. The system stays yours.
Maintenance
An agreed response time, monitoring and a monthly allocation for enhancements.
Related work
FAQ
What do you need to get started?
A list of the systems, interface documentation or a contact at the vendor, access to a test environment and sample data. If there is no documentation, we produce it as part of the analysis.
What if the external system has no API?
We use file exchange, a scheduled import or a connection through an intermediate database. The approach depends on what the system allows and how fresh the data has to be.
What happens when a transfer fails?
The record is not lost. The transfer is retried under an agreed rule, failed records stay visible and the responsible person is alerted; a single transfer can also be re-run manually.
Can you build the integration without changing our existing system?
Often yes - through the existing interfaces or an intermediate layer. Where the system does not expose what is needed, a change is unavoidable; we establish that during the analysis, not mid-build.
Who is responsible for poor-quality data?
Data quality is a business question, not a technical one. We surface the problems, propose cleaning rules and implement them, but the decision on the correct value stays with the client.
Can you take over an integration built by someone else?
Yes, after reviewing the implementation, the credentials and the documentation. The review produces findings, a risk list and a stabilisation proposal.
Related reading
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.