Enterprise integration & APIs
The middleware between your ERP, storefront, CRM and payment provider — built to be idempotent, observable and safe to retry, because integrations fail and yours should survive it.
Integration is the work of getting separate systems to share data and trigger each other reliably — an order in the storefront becoming a record in the ERP, a payment becoming an invoice, a stock movement in the warehouse becoming an availability change on the website.
It sounds like plumbing, and it's where a surprising share of operational pain actually lives. When integrations are done casually — a script on someone's machine, a nightly CSV, a webhook with no retry — the failure mode isn't a loud error. It's a slow divergence, where two systems quietly disagree and nobody notices until a customer does.
The engineering that matters here is unglamorous: idempotency so a retry doesn't double-charge, ordering guarantees, dead-letter queues for what can't be processed, and observability so you can answer 'did that order reach the ERP' without opening a database.
Most landscapes need a mix. Choosing deliberately is what stops the mix becoming a mess.
| Point-to-point | Message queue / event bus | API gateway / hub | |
|---|---|---|---|
| How it works | System A calls system B directly | Producers publish events; consumers subscribe | One layer all systems talk through |
| Best for | Two systems, simple and stable | Asynchronous work, spiky volume, fan-out | Many systems, shared auth and policy |
| Failure behaviour | Caller must handle retries itself | Buffers naturally; replay is possible | Central place to retry and observe |
| Scales to | Poorly — links grow quadratically | Well | Well |
| Operational cost | Low at first, high later | Moderate — a broker to run | Moderate — a gateway to run |
| Watch out for | The nightly CSV nobody owns | Ordering and duplicate delivery | Becoming a bottleneck for every team |
We won't propose a message broker for two systems that talk once an hour. Matching the pattern to the actual volume matters more than architectural purity.
Six services covering the connective tissue between your systems.
API design & development
REST and GraphQL APIs designed to be consumed — versioned, documented, with consistent errors and pagination that works past page one.
System integration
Connecting ERP, CRM, e-commerce, warehouse, accounting and payments — including the legacy systems whose only interface is a file drop or a database view.
Middleware & event pipelines
The layer that transforms, routes, retries and records. Where the business rules about how systems talk actually live.
Legacy system wrapping
Putting a modern, documented API in front of a system you can't replace yet, so new work doesn't have to inherit its interface.
API gateways & management
Authentication, rate limiting, quotas and usage analytics in one place — particularly when you're exposing APIs to partners or customers.
Data synchronisation
Keeping records consistent across systems, with a defined source of truth per field and an explicit answer to what happens when two sides change at once.
Five properties we build in by default. Their absence is why integrations become a permanent support burden.
Idempotency
The same message processed twice must not create two orders or two charges. Every write path carries an idempotency key, so a retry after a timeout is always safe.
Retries with backoff
Transient failures are the normal case, not the exception. Automatic retry with exponential backoff, and a dead-letter queue for anything that genuinely can't be processed.
Observability
Every message traceable end to end. When someone asks whether a specific order reached the ERP, that's a search, not an investigation.
Reconciliation
A scheduled job that compares both sides and reports drift. Even good integrations diverge eventually; the difference is whether you find out or your customer does.
Explicit contracts
Schemas that are versioned and validated at the boundary, so an upstream change breaks loudly at the edge rather than corrupting data three systems downstream.
Not exhaustive — if it has an API, a database or even a file export, it can usually be integrated.
ERP & accounting
- SAP
- Oracle
- Microsoft Dynamics
- Tally
- Zoho Books
- QuickBooks
CRM & sales
- Salesforce
- HubSpot
- Zoho CRM
- Pipedrive
Commerce
- Shopify
- WooCommerce
- Magento
- Custom storefronts
Payments
- Stripe
- Razorpay
- PayPal
- Adyen
- Bank host-to-host
Logistics
- Carrier APIs
- WMS
- Fleet tracking
- EDI
Messaging & notifications
- SMS & WhatsApp APIs
- Webhooks
- Push
Where a system has no API, we integrate at the database or file level — carefully, and behind a wrapper so the rest of your estate never sees that detail.
It works until it doesn't, and the failure is usually silent — a malformed row skipped, a file that didn't arrive, a timezone that shifted the cutoff. Batch transfer is a legitimate pattern for genuinely daily data, but it needs validation, alerting and reconciliation around it. If the business actually needs near-real-time, batch is quietly costing you more than it saves.
Start a project
Tell us what they are and how they're connected today. We'll come back with the pattern that fits and what it takes to make it reliable.
- Reply within one business day
- Free scoping session, no obligation
- You keep the scope document either way