Service
API & System Integrations
We connect the systems your business already runs on, with integration layers that handle failure explicitly rather than pretending it will not happen.
What is system integration?
System integration is connecting separate software systems so data and events flow between them reliably. It covers mapping data models that were never designed to agree, choosing synchronous or event-driven transport, handling authentication and rate limits, and making failures visible and recoverable rather than silent.
The difficult part is rarely the API call. It is what happens when the third system is down, when a record was partially written, when the same webhook is delivered twice, or when two systems disagree about which record is authoritative.
Most businesses run eight or ten systems that each hold part of the truth. The ERP knows the job, the CRM knows the customer, the field application knows what happened on site, and the compliance platform knows whether the contractor was allowed to be there. When these do not talk, people become the integration.
We build an integration layer that owns the mapping, the transport and the failure handling. Operations are idempotent so a retry cannot duplicate. Failures land in a dead letter queue with enough context to replay them. Every sync is observable, so drift is detected rather than discovered by a customer.
Business problems
What this usually solves.
The situations clients describe when they start this conversation.
Staff re-keying the same data
The same job, customer or contractor is entered into several systems, and the copies diverge within weeks.
Integrations that fail silently
A sync stops working and nobody notices until a downstream process produces the wrong result.
Point-to-point sprawl
Every system connects directly to every other, so a change in one API requires changes in several places.
Duplicate records from retries
Operations are not idempotent, so a timeout followed by a retry creates a second record rather than completing the first.
Capabilities
What we bring to it.
Integration architecture
A clear boundary between systems, with canonical models and adapters instead of direct point-to-point coupling.
API development
REST and GraphQL interfaces over internal systems, versioned, documented and authenticated for external consumers.
Event-driven sync
Webhooks, message queues and change data capture for near real-time propagation without polling everything.
Reliability engineering
Idempotency keys, exponential backoff, circuit breakers, dead letter queues and replay tooling.
Data mapping and reconciliation
Field-level mapping with transformation rules, plus scheduled reconciliation that reports divergence.
Monitoring and alerting
Per-integration dashboards showing throughput, latency, error rate and queue depth, with alerts that reach a human.
Deliverables
What we build
- ERP to CRM synchronisation with conflict rules and audit history
- Field service and job management integrations such as Simpro
- Compliance platform integrations such as Rapid Global
- Payment and finance system integrations including Stripe and accounting platforms
- Messaging integrations over WhatsApp Business and email providers
- Public APIs and webhook infrastructure for your own customers and partners
Stack
Technology approach
We assume every external system will be unavailable at some point, and design so that this is an inconvenience rather than an incident.
| Layer | What we use |
|---|---|
| Transport | REST, GraphQL, webhooks, message queues, scheduled batch where required |
| Runtime | Node.js services with queue workers for long-running synchronisation |
| State | PostgreSQL for mapping tables, sync cursors and reconciliation records |
| Reliability | Idempotency keys, backoff, circuit breakers, dead letter queues |
| Security | OAuth 2.0, managed identities, secret rotation, signed webhook verification |
| Operations | Per-integration telemetry, replay tooling and reconciliation reports |
Process
How we deliver.
- 01
Discover
Understand business requirements and existing systems.
- 02
Architect
Design product, cloud, integration and data architecture.
- 03
Engineer
Build production-grade software.
- 04
Launch
Deploy, integrate and validate.
- 05
Scale
Optimize, monitor and evolve.
Case studies
Relevant work
FAQ
API & System Integrations — questions we are asked
What if a system has no API?
There is usually a supported alternative: a database view, a scheduled export, an SFTP drop or a vendor integration endpoint. Where none exists we build an adapter around what is available and isolate it, so the rest of the architecture is not shaped by that limitation.
Real-time or scheduled synchronisation?
Event-driven where the business needs current data and the source supports webhooks or change capture. Scheduled batch is entirely appropriate for reference data and reporting, and is more resilient. Most estates use both.
How do you prevent duplicate records?
Idempotency keys on every write, so a repeated request completes the original operation rather than creating a second one, plus deterministic external identifiers that let the target system recognise a record it has already seen.
Which system owns a record when two disagree?
That is decided during design, per entity and sometimes per field. One system is authoritative, the others are followers, and the rule is written down. Integrations that skip this step produce conflicts nobody can resolve.
Planning api & system integrations work?
Tell us about the systems involved and the constraints. We will come back with an architecture and a delivery sequence.