Systems integration

A typical business runs a website, a CRM, an accounting package, a payment provider, a booking tool and a messaging channel. Each was chosen sensibly on its own. Between them sit the gaps, and in those gaps sit people copying data from one screen into another, which is slow, error-prone and entirely invisible in any budget.

Integration work closes those gaps. It is unglamorous, it is where a large share of practical operational improvement actually comes from, and it is usually cheaper than replacing any of the systems involved.

Why this is worth doing properly

The economics favour integration over consolidation. Replacing a working system to reduce the number of systems is expensive, disruptive and frequently produces a worse fit. Connecting them properly costs a fraction and keeps each tool doing what it is good at.

The difficulty is that integrations are where responsibility becomes ambiguous. Each vendor supports its own product and nobody owns the space between them, so when a sync fails the answer from both sides is that their system is working correctly. Somebody has to own the connection itself, including the monitoring.

Direction of truth is the design decision that matters most. When two systems both hold a customer record and both can edit it, you need an explicit rule about which one wins, or you get silent divergence that surfaces months later as two versions of the same customer with different addresses.

Where this work usually goes wrong

Two-way sync without a rule for conflicts

If both systems can edit the same field, something must decide which change wins. Without that rule, records diverge quietly and nobody notices until a bill goes to an old address.

No idempotency

Webhooks get delivered more than once. An integration that creates a record every time it receives a message will produce duplicates under retry, which is a normal condition rather than an edge case.

Failing silently

A sync that stops working without alerting anyone means the two systems drift apart while everyone assumes they are aligned. Failure alerting is the core requirement, not an addition.

No handling of rate limits

Bulk operations that ignore API limits get throttled or blocked mid-run, leaving a partial state. Backoff and resumable processing belong in the first version.

Undocumented field mappings

Six months later nobody remembers why a field maps the way it does, and changing anything becomes archaeology. The mapping is documentation that has to be maintained.

What this covers

Website-to-CRM integration

Form submissions into the CRM with source, campaign and consent status preserved.

CRM-to-accounting integration

Won deals becoming invoices without re-entry, with reconciliation back to payment status.

E-commerce integrations

Orders, stock, customers and fulfilment synchronised between storefront and back office.

Payment-system integration

Stripe and regional providers connected to orders and accounting, including refunds and chargebacks.

Gmail and Google Calendar integration

Mail and calendar tied to CRM records so history and availability are visible where decisions are made.

WhatsApp integration

Business API conversations logged against the contact record rather than living on someone’s phone.

Booking-system integration

Appointments creating CRM activity, reminders and, where relevant, invoices.

POS and inventory integrations

In-person sales and stock reflected in the same system as online.

ERP integration

Connections to the system of record for stock, purchasing and finance, respecting its constraints.

Marketing-platform integration

Audiences, consent state and campaign data flowing both directions with suppression respected.

Social-media platform integration

Lead forms, messaging and ad platform conversion feedback wired into the CRM.

Custom API development

Building the endpoint that does not exist, documented and versioned, when a vendor offers no suitable one.

Legacy-system integration

Connecting older systems through files, database access or a wrapper API where no modern interface exists.

Data synchronisation between platforms

Scheduled and event-driven sync with conflict rules, idempotency and reconciliation reporting.

How the work runs

1. Map the data and the direction of truth

   Which system owns which field, which direction each flows, and what happens on conflict. Agreeing this before building prevents the class of problem that is hardest to detect afterwards.

2. Design for repeat delivery

   Idempotent operations keyed on a stable identifier, so a duplicated webhook or a retried job cannot create duplicate records.

3. Handle limits and failure

   Rate limit backoff, resumable batches, dead-letter handling for messages that cannot be processed, and alerting when anything lands there.

4. Reconcile continuously

   A scheduled comparison of record counts and key fields across systems, reporting divergence. This is how silent drift gets caught.

5. Document the mapping

   Field-by-field mapping with transformation rules, maintained as the integration changes, so future work is not reverse engineering.

6. Monitor and own it

   Somebody has to own the space between the vendors. Under a support arrangement that is us, with a defined response window.

What you receive

• Data map with direction of truth and conflict rules
• Built integrations with idempotent processing
• Rate-limit handling and resumable batches
• Dead-letter queue and replay procedure
• Reconciliation reporting
• Field mapping documentation
• Monitoring and failure alerting
• Runbooks for common failures

You probably need this if

• Somebody copies orders from one system into another.
• Your CRM and accounting system disagree about a customer.
• WhatsApp conversations with customers live on personal phones.
• Duplicate records keep appearing and nobody knows why.
• A sync broke and you found out from a customer.

What we build and work with

Integration glue chosen so it can be inspected, versioned and run wherever the data is permitted to be.

n8n, self-hosted

The default connector layer, self-hosted so data stays on your infrastructure and there is no per-execution charge at volume.

Custom Python services

Where an integration needs logic, state or performance beyond what a workflow tool expresses clearly.

Webhook receivers with queueing

Inbound events accepted quickly and processed asynchronously, so a slow downstream system cannot cause dropped deliveries.

PostgreSQL

Sync state, idempotency keys and reconciliation history, so the integration can answer what it did and when.

Vendor APIs and SDKs

Official interfaces used within their terms and rate limits, with version changes tracked.

Monitoring and dead-letter alerting

Failed messages surfaced to a human rather than discarded, with a defined replay procedure.

Version control

Workflow definitions and mappings committed, so changes are reviewable and recoverable.

What changes once this is in place

Nobody re-types data

Records move between systems automatically, removing both the labour and an entire class of transcription error.

Divergence is detected

Scheduled reconciliation reports mismatches, so the two systems cannot drift apart unnoticed for months.

Duplicates stop appearing

Idempotent processing keyed on stable identifiers, so retried deliveries do not create second copies.

Someone owns the gaps

The space between vendors has a named owner with monitoring and a response window, rather than being nobody’s problem.

Keep the tools that work

Connecting systems rather than consolidating them avoids an expensive migration and a worse fit.

How this differs by market

The work is the same craft everywhere. What changes is the law, the language and the buying culture — and those change enough to matter.

European Union

Moving personal data between systems is processing under the GDPR, requiring a lawful basis, purpose limitation and processor agreements with each vendor in the chain. Where an integration crosses a border, the transfer mechanism has to be documented. Consent state must travel with the record, or a suppression in one system will not be honoured in another.

Nordics

National e-invoicing standards and the Peppol network are widely used across the Nordic countries, and accounting integrations frequently need to speak them rather than exchanging PDFs. BankID and MitID identity flows also commonly need connecting to CRM and booking systems.

United States and Canada

Sector requirements shape what may be connected: HIPAA business associate agreements for health data, PCI scope boundaries limiting where card data can flow. Consent state matters particularly for Canadian records, since CASL obligations follow the contact across systems.

United Arab Emirates

WhatsApp is a primary commercial channel, so integrating the Business API into the CRM is frequently the highest-value single integration available. VAT handling must be correct in any order-to-invoice flow, and DIFC or ADGM entities may face constraints on where integrated data can be processed.

Not legal advice. Regulatory summaries on this site describe how we scope and build, and are current to our latest review. Verify the operative text with qualified counsel in the relevant jurisdiction before relying on it.

How we know it worked

Sync success rate, reconciliation divergence count and mean time to detect a failure. Divergence count is the honest measure of whether the integration is doing its job, and it should trend toward zero and stay there.

We also measure manual handling time removed against a baseline captured before the work. Where no baseline exists we say the saving is unmeasured rather than estimating it.

Duplicate record creation is tracked explicitly after launch, because it is the most common symptom of an integration that works in testing and fails under real retry conditions.

Estimates are labelled as estimates. Any figure on this site that describes a range is a planning estimate with its assumptions stated, not a measured client outcome. We do not publish client results without the client's permission and a date.

Related services

Sectors where this is usually the lead engagement

These are the industries where this discipline is typically the first thing a client buys rather than something added later. The link goes to a page written for that sector specifically, with a paragraph on this service and on every other one.

• Manufacturing & Industrial — Excellent products, world-class production, and commercial systems that have not been touched in a decade. That gap is the opportunity.
• Logistics & Freight — One of the fastest-moving sectors for AI adoption, and one where most of the value is still locked in email attachments.
• Healthcare & Clinics — One of the fastest-growing sectors for digital investment, and the one where the constraints on what you may say and where data may sit shape everything.
• Construction & Engineering — The fastest-accelerating sector for AI adoption, running on drawings, variations and payment applications that arrive as PDFs.
• E-commerce & Retail — The third-largest sector for digital transformation spending, and the one where a business can grow revenue while losing money on every order.
• Accounting & Tax — A profession being reshaped twice at once — by e-invoicing mandates arriving across Europe, and by the automation of the compliance work that used to pay for everything.
• Automotive & Mobility — A sector where the manufacturer sets the rules, the margin is in aftersales, and lead response time decides who sells the car.
• Energy & Utilities — Enormous operational data volumes, heavy regulatory reporting, and customer systems that were built for a market that no longer exists.
• Travel & Tourism — Long research cycles, multilingual audiences, and package regulation that turns a bundled booking into a legal obligation.
• Wholesale & Distribution — Thin margins, enormous SKU counts and customer-specific pricing that lives in a system nobody wants to touch.
• Food & Beverage Production — Traceability obligations that must survive a recall, retailer requirements that exceed them, and a direct channel most producers have never built.
• Fintech & Payments — Startup growth expectations inside a supervised institution, where onboarding conversion and financial crime obligations pull in opposite directions.
• Pharma & Life Sciences — Where data integrity is a regulatory obligation, promotion to the public is largely prohibited, and every system that touches quality must be validated.
• Medical Devices — Where the documentation is the product as far as a regulator is concerned, and post-market surveillance never ends.
• Public Sector — Where accessibility is law, procurement is formal, and the service has to work for everyone rather than for a target segment.

It appears on all thirty sector pages, because every one of them carries a paragraph on all twenty-two services. This list names only the sectors where it tends to lead.

Where we deliver this

This service is delivered across the European Union, the Nordic countries, North America and the United Arab Emirates. The craft does not change; the law, the language and the buying culture do. Consent regimes, invoicing mandates and payment conventions differ enough between markets that a campaign or a system built for one frequently cannot be used unchanged in another.

Each country page sets out what actually differs there and what it means for scope — all 32 countries and 10 cities are listed here. A few of the markets we work in most:

• Germany
• Netherlands
• France
• Sweden
• United States
• United Arab Emirates