Home / Services / S/04 Systems Integration

Systems integration
built around your operation.

We connect ERP, WMS, ecommerce, CRM, EDI and legacy software, then make failures visible. Every data flow has a named owner, a recovery path and evidence that each record arrived.

Discuss what changed What we build

Capabilities

What we build.

01 — 04

ERP & operational systems

Connect orders, stock, customers, invoices and payments without asking staff to rekey or reconcile the same event.

APIs & webhooks

Build secure, documented interfaces with versioned contracts, clear authentication and safe retry behaviour.

EDI & partner connectivity

Orders, despatch advice, invoices and acknowledgements mapped and reconciled across trading partners.

Queues, exceptions & monitoring

Keep work moving when a supplier or platform is unavailable, and show every failed record to the person who can act.

ERPRESTWebhooksEDIQueuesOAuthMonitored end to end

How we do it

What keeps a data flow dependable.

A/01

Start with the business event

We follow one order, payment or stock movement through every system before choosing the interface.

A/02

Make failure visible

Timeouts, retries, alerts and reconciliation are part of the first design. Each exception has an owner and recovery path.

A/03

Leave a system your team can run

We document every contract, mapping, credential, alert and recovery step, then hand over the code and runbook.

Scope the data flow before choosing middleware

Integration readiness scorecard.

Score one complete business event instead of a vague ambition to "connect the ERP". Start with an accepted order reaching fulfilment, a delivered order becoming an invoice or a payment updating the service record.

Score one connection from 0 to 3

Every slider starts at 1 because an untested assumption is not evidence. Score one real flow—for example, accepted order from ecommerce to ERP—using what the system owners and representative records can prove today.

Is the source of truth agreed? 1 / 30: Records conflict or ownership is disputed3: One named system owns each recordCan both systems be accessed safely? 1 / 30: Interfaces, credentials or contracts are unknown3: Documented access and a test environment existAre representative records mapped? 1 / 30: Fields and identifiers are assumed3: Normal and awkward examples are mappedAre timing and volume explicit? 1 / 30: Frequency, peaks and latency are unknown3: Volumes, peaks and freshness needs are measuredIs failure handling designed? 1 / 30: Failures would be silent or handled ad hoc3: Retry, exception and reconciliation paths are ownedAre identity and permissions bounded? 1 / 30: Shared credentials or broad access are expected3: Least-privilege access and audit needs are agreedCan the data flow be tested realistically? 1 / 30: No safe test data or acceptance cases3: Representative cases and expected outcomes existWho will own the live connection? 1 / 30: No support owner, alert route or service level3: Named owner, runbook and response path exist

Scope readiness8 / 24

Resolve the integration boundary first

The connection still depends on disputed records, uncertain access or an unowned failure path. Discovery should produce a source-of-truth map, representative examples and a named operating owner before a delivery estimate is treated as firm.

Send the result and your optional context to ORBN for a personal response.

This is directional scoping support, not an architecture or security review. One severe constraint—such as prohibited access, unacceptable data loss or an unsupported vendor—can outweigh the total.

Business systems integration services

The systems we connect.

For every data flow, we name the application that owns the record, which systems may change it, how quickly the update must travel and what the business does when it cannot.

I/01

ERP and finance integration

Connect customers, products, orders, invoices, credit status and payments without making staff reconcile the same commercial event across several systems.

I/02

WMS, stock and fulfilment

Move accepted demand into the warehouse, return picks, substitutions and stock movements, and make dispatch status visible to service and planning teams.

I/03

Ecommerce and B2B ordering

Apply account pricing, availability and ordering rules at the customer interface, then carry the order into the operational source of truth without rekeying.

I/04

CRM and service workflows

Bring account, case, order and payment context into the place service teams work while keeping one authoritative owner for each record.

I/05

EDI and trading partners

Exchange purchase orders, acknowledgements, despatch advice, invoices and other agreed documents with customers, suppliers or logistics partners.

I/06

Logistics, payments and specialist platforms

Connect carriers, route planning, payment services, marketplaces, identity providers and industry-specific tools. If a third party fails, the affected work stays visible.

API, EDI, events or files

Match the interface to the job.

Real-time APIs suit some flows; EDI or scheduled files suit others. Latency, volume, vendor control, document standards, recovery and the cost of stale data determine the useful pattern.

Scroll horizontally to compare the approaches →

Pattern	Good fit	Important constraint	Control to require
REST or GraphQL API	Requesting current data or performing a defined operation	Availability, rate limits, versions and response latency	Documented contract, authentication, timeouts and safe retry behaviour
Webhook	A source can notify consumers soon after an event	Delivery can be repeated, delayed or arrive out of order	Signature validation, durable receipt, deduplication and replay
Event or message queue	Systems must absorb peaks and continue when a consumer is unavailable	Eventual consistency and more operational components	Stable event identity, retry policy, dead-letter path and traceability
EDI	Trading partners exchange agreed commercial documents	Partner standards, mapping variants, acknowledgements and batch timing	Versioned maps, control totals, acknowledgements and exception ownership
Secure scheduled file	A vendor supports reliable imports or exports but no suitable API	Data is only as fresh as the schedule and partial files can mislead	Encryption, atomic transfer, checksums, archive and reconciliation
Database view or legacy wrapper	Stable records must be exposed from an older application	Tight coupling can bypass application rules and vendor support	Read-only or governed access, schema containment and an exit plan

From workflow to monitored service

How we take an integration into production.

FLOW / 01

Map the real business event

Follow a representative order, product, stock movement, invoice, payment or case through people and systems. Name every source of truth, manual intervention, exception and deadline.

Confirm access and support boundaries

Inspect vendor documentation, contracts, credentials, rate limits, environments, data rights, support contacts and planned version changes before treating connectivity as solved.

Define the data contract

Map identifiers, fields, validation, transformations, units, status changes and ownership. Include incomplete, repeated, reversed and out-of-order examples alongside the clean record.

Prove the hardest seam

Use representative data to test the uncertain vendor call, legacy access path, performance constraint, EDI map or matching rule before extrapolating a full programme.

Build recovery from the start

Build authentication, idempotency, validation, retry, quarantine, useful logs and reconciliation into the connection from the first production design.

Run in parallel, then cut over

Compare outputs, prove control totals, train the owners, rehearse rollback and decide exactly when the old transfer or manual step stops carrying responsibility.

Monitor, support and change

Watch business outcomes as well as technical uptime, maintain the runbook, review recurring exceptions and control credentials, schemas, versions and vendor changes over the life of the service.

A connection your team can run

What every production data flow needs.

The architecture changes with the systems and the cost of failure. Before a data flow replaces manual checking, each of these responsibilities needs a design, supporting evidence and a named owner.

P/01

Authority and least privilege

Use separate service identities, scoped permissions, protected secrets and an audit trail. The integration should only read or change the records its purpose requires.

P/02

Idempotency and ordering

Give each business event a stable identity and make repeats safe. Define what happens when messages are duplicated, delayed, missing or received in a different order.

P/03

Timeouts, retries and containment

Stop waiting at a known point, retry only conditions that may recover and back off under pressure. Send exhausted work to an owned exception path.

P/04

Validation and reconciliation

Reject malformed or unauthorised changes at the boundary. Independently compare consequential totals and records so a technically successful request cannot hide a business mismatch.

P/05

Observability and recovery

Trace a business record end to end, measure age and failure rate, alert the person who can act, and document replay, correction, fallback and vendor-escalation procedures.

P/06

Contracts and controlled change

Document the interface, examples, errors, limits and support path. Test compatible schema and version changes, rotate credentials and give consumers time to move before retiring behaviour.

Third-party failures need a planned response. The GOV.UK API guidance suggests queueing work for later, offering another service or using an alternative system. The NCSC's guidance on securing HTTP-based APIs covers development, authentication, input validation, denial-of-service protection, logging and monitoring. The OpenAPI Specification defines a standard contract that people and software can read. These sources are a starting point. Each integration still needs its own threat model, operating design and acceptance tests.

Cost and timeline

What affects integration cost and timeline.

Endpoint count is a poor estimate on its own. One payment or stock flow can need more assurance and recovery work than ten read-only lookups. The estimate should cover interface quality, mapping, data correction, identity, testing, cutover and continuing ownership.

DISCOVER

Boundary and evidence

Map the workflow and sources of truth. Confirm vendor access, sample records, volume, timing, security, the cost of failure and who will operate the connection.

PROVE

The hardest complete flow

Prove one record path through real interfaces. Include identity, awkward mappings, duplicate or failed delivery and the evidence needed to plan production.

OPERATE

Production and lifecycle

Build the remaining flows and environments, then cover monitoring, reconciliation, parallel running, cutover, support, vendor coordination and controlled change.

A focused proof can move quickly when documentation, test access and sample records are ready. An ERP, EDI or legacy programme must also account for the organisations and contracts on each side of the interface. Use the UK software delivery cost estimator to test team, duration and risk assumptions without pretending every integration has the same shape.

Integration inside an operational workflow

Crowbond cut route planning from as much as eight hours to under 20 minutes.

WORK / 01

DIRECT OMS INTEGRATION

200+ daily orders flow into route planning.

Crowbond had trialled a separate logistics product, but moving data still left manual work. ORBN connected the existing order management system directly to a multi-vehicle optimiser, retained human override and used the established access controls. Planning fell from as much as eight hours to less than 20 minutes, with more than £36,000 in reported annual savings.

OMS integrationRoute optimisationExisting identityHuman override

Read the Crowbond route optimisation case study

Crowlite foodservice operations dashboard connected to order and route workflows

Results reported for this engagement. Outcomes vary with the operation, workflow and starting point.

CRM and payment modernisation

A publisher moved 8,000+ direct debits into Stripe and Salesforce.

Salesforce already held the publisher's customer context. ORBN kept it in place, replaced a 12-year-old payment capability with Stripe and connected the service workflow to the existing CRM.

8,000+

Active direct debits migrated

Historic product records were mapped into the new payment model and reconciled through the transition.

6 months

Controlled transition

The work covered migration, CRM workflow, training and cutover across the full six-month transition.

£72k

Reported annual saving

The reported figure compares the former platform's operating cost with continuing Stripe and transaction fees.

Read the publisher payment modernisation case study

Frequently asked questions

API and systems integration FAQ.

Q/01

What is systems integration?

Systems integration makes separate applications exchange data or trigger work as one controlled business process. A production integration also covers data mapping, identity, validation, monitoring, failure recovery, reconciliation, documentation and ownership. The code that moves a record is only one part.

Q/02

Can you integrate an ERP or legacy system that has no modern API?

Often, yes. The practical options include vendor connectors, EDI, secure file transfer, supported imports or exports, read-only database views, controlled browser automation and small wrappers around stable legacy behaviour. We choose between them based on vendor support, data volume, timing, security and failure recovery. Direct database writes are normally a last resort because they can bypass business rules and vendor support boundaries.

Q/03

What is the difference between API integration and EDI?

An API usually exposes operations or data for software to request, often in near real time. EDI exchanges agreed business documents such as orders, despatch advice and invoices using trading-partner standards and may be processed in batches. Neither is inherently better: an organisation may use APIs inside its operation and EDI at a customer or supplier boundary where the document contract and partner network matter more than immediate response.

Q/04

How much does a systems integration project cost in the UK?

Cost depends on the number of flows, interface quality, record complexity, data cleanup, security, test access, volume, recovery, cutover and support. A useful proposal prices discovery, the hardest technical proof, production delivery and ongoing operation separately. A documented API connection and an ERP programme with several partners, historic data and no test environment are different projects, so one fixed integration price would be misleading.

Q/05

How long does API or ERP integration take?

A bounded connection can sometimes be proven in weeks when both interfaces are documented, representative records and test credentials exist, and one owner can answer mapping questions. Production takes longer when vendors, identity, data quality, trading partners, migration, parallel running or service levels need coordination. The first estimate should show those assumptions instead of hiding them inside one delivery date.

Q/06

How do you prevent duplicate orders or payments?

Use a stable business or idempotency key, make repeat processing safe, record what has been accepted, and distinguish a timeout from a confirmed rejection. Retries should be bounded and observable. For consequential records such as orders, stock, invoices or payments, an independent reconciliation should compare the systems of record and route differences to an accountable owner.

Q/07

Who monitors and supports an integration after launch?

That responsibility must be clear before launch. ORBN can provide monitoring and support or hand the service to an internal or third-party team. Either way, the connection needs useful logs and metrics, alert thresholds, a runbook, named owners, vendor contacts, recovery instructions and an agreed process for schema, credential and API version changes.

Q/08

Do we need to replace our existing systems before integrating them?

Not necessarily. Integration can keep a dependable system of record in place while removing rekeying, spreadsheets or a missing workflow around it. It can also create a controlled boundary for gradual modernisation. Compare the system's remaining life, support and data quality with the cost and risk of replacement. Avoid building an unowned permanent facade around software that is already unsafe to operate.

Plan the surrounding system

Decide what to connect, retain or replace.

Integration can keep reliable systems in place while removing manual work around them. Some dependencies still need replacement. If teams disagree about a record's meaning or owner, start with data strategy and analytics. The guides below help frame the wider software, ERP and modernisation decision around the first data flow.

R/01

Two systems.
One record that must arrive.

Bring the handoff, one real record and the consequence when it fails. We will define the ownership, boundary and riskiest assumption.

Talk through the situation hello@orbn.co.uk