Skip to content
ERP Builders

Service · Data & Integration

ERP integration that does not depend on someone noticing it broke

Most businesses have more systems than they think: a web shop, a marketplace or two, a CRM, a payment provider, a shipping platform, a bank, a payroll tool, a BI dashboard. Each one either talks to the ERP automatically or relies on someone exporting, cleaning and importing files.

Overview

What erp integration involves

Integrations remove that manual work, but only if they are built to run unattended. The common failure is not that an integration never worked — it is that it failed silently for three days and nobody noticed until a customer complained.

01The problem

Where things usually go wrong

01

Two systems, both the 'master'

Customer addresses or product prices edited in both places, overwriting each other unpredictably.

02

Silent failures

An API token expires or a field changes, orders stop syncing, and nobody finds out until month-end reconciliation.

03

Duplicates from retries

A timeout triggers a retry, and the order is created twice — once from each attempt.

04

Point-to-point spaghetti

Each system connected directly to every other system with scripts nobody fully understands.

02Our approach

How we handle it

Every integration starts with a data ownership map. For each entity — customers, products, prices, stock, orders, invoices, payments — we decide which system is the source of truth, which fields flow where, and in which direction. That single document prevents most of the problems we are later asked to fix.

We then choose a pattern suited to the volume and latency: event-driven webhooks for orders and payments, scheduled batches for catalogues and price lists, a middleware layer when several systems share data. Every write uses an idempotency key so retries are safe. Failures retry with backoff, then land in a dead-letter queue that someone can see, fix and replay.

Integration flow from Commerce / CRM through an integration layer with queueing, mapping and retries into ERPSOURCECommerce / CRMwebhook · RESTINTEGRATION LAYERValidate + mapQueue (idempotent)Retry w/ backoffDead-letter + alertSYSTEM OF RECORDERPorders · stock · ledgerINBOUND (ORDERS, CUSTOMERS)OUTBOUND (STOCK, STATUS, INVOICES)

03Capabilities

What the work covers

01

Commerce and marketplaces

Orders, stock, products, prices, fulfilment and returns with Shopify, WooCommerce, Amazon and others.

02

CRM

Accounts, contacts, opportunities and quotes synchronised with Salesforce or HubSpot.

03

Payments and banking

Payment matching, payouts, fees and refunds from Stripe, PayPal and bank feeds.

04

Accounting platforms

Journals and invoices to QuickBooks or Xero during transitions or for subsidiaries.

05

Logistics and carriers

Shipment creation, labels, tracking numbers and proof of delivery.

06

Custom and legacy systems

APIs, databases, file drops, EDI and machines — whatever the other side offers.

04Technical considerations

Details that decide whether it holds up

01

Idempotency

Each message carries a unique key; the receiver ignores duplicates, so retries never create double orders or payments.

02

Retry and dead-letter

Exponential backoff with jitter for transient errors; permanent failures move to a visible queue with the error and payload.

03

Rate limits and batching

Respect provider limits by batching changes and spreading load, rather than firing one call per stock movement.

04

Observability

Structured logs searchable by order number or SKU, metrics on throughput and failures, and alerts to a named owner.

05Process

How the engagement runs

  1. 01

    Map

    Systems, entities, volumes, data ownership and direction of sync.

  2. 02

    Design

    Integration pattern, field mapping, error handling and monitoring approach.

  3. 03

    Build

    Connector development with tests against sandbox APIs and realistic data.

  4. 04

    Test

    Volume tests, failure simulation (timeouts, bad data, expired tokens) and reconciliation.

  5. 05

    Operate

    Go-live with monitoring and alerting, and a runbook for common failures.

06Outcomes

What you should expect afterwards

No more re-keying

Orders, payments and stock move between systems automatically.

Failures are visible

When something breaks, the right person knows within minutes and can replay the message.

Consistent data

Clear ownership rules stop systems overwriting each other.

Where it applies

Industries and systems we commonly see

Insights

Related reading

ERP Integrations2 min read

RFID Integration with Odoo: A Practical Architecture

How to integrate RFID readers with Odoo inventory: middleware design, mapping EPCs to products and serials, receiving and counting flows, performance and what to build vs buy.

FAQ

Frequently asked questions

Should we use an off-the-shelf connector or build a custom integration?

Evaluate the existing connector first against your rules for customers, taxes, variants and fulfilment. If it fits with little modification, use it. If it needs heavy changes, a purpose-built integration is usually cheaper to own.

Real-time or batch?

Orders and payments generally benefit from near-real-time sync. Catalogues, price lists and reconciliations are usually fine in batches. Real-time everything adds cost and fragility without much benefit.

Who monitors the integrations after go-live?

Alerts go to a named owner on your side and, under a support plan, to us. Each integration has a short runbook explaining common failures and how to resolve them.

Can you integrate with a system that has no API?

Often, yes — through database access, scheduled file exports, email parsing or, as a last resort, controlled screen automation. We will explain the tradeoffs of each.

Consultation

Need systems talking to each other?

List the systems and the data. We will outline the architecture, the risks and the effort.