Enterprise Integration Services
APIs, ERP and CRM connections, EDI, message queues and data pipelines. We map what your systems actually do, decide who owns each record, and build connections that survive one side going down.
The Problem Integration Work Is Actually Solving
Integration projects are usually requested in technical language and caused by something else. A finance team is rekeying orders from one screen into another. A customer's address is right in the CRM and wrong on the invoice, and nobody can say which system should win. Stock is oversold because the website's view of inventory is forty minutes stale. Month-end takes four days because three exports have to be reconciled by hand.
None of those are connectivity problems. They are agreement problems that show up as connectivity problems. Two systems can be perfectly well connected and still disagree, because no one ever decided which of them is authoritative for a customer record, or what should happen when both are edited on the same afternoon.
So the first phase of our integration work is not code. It is a map of what currently exchanges data with what, by which mechanism, on what schedule, and who owns each end. In most estates that document does not exist anywhere before we produce it, and it routinely changes what people thought the project was.
What Do We Integrate?
ERP integration
ERP systems are usually the system of record for finance, and that makes them the most consequential thing to integrate and the least forgiving to get wrong. The common flows are orders in, invoices and credit notes out, stock levels both directions, product and price master data outward, and the general-ledger postings that finance will reconcile.
The technical route depends on the product. SAP exposes OData services and IDoc messaging; Dynamics 365 has a well-documented web API; NetSuite has SuiteTalk and RESTlets; Odoo has an XML-RPC and JSON-RPC interface; Tally, still very widely used in India, is typically integrated over XML. Older on-premise installations may offer nothing but a database and a scheduled export directory. We work with what is there rather than insisting on a modernisation you have not asked for.
The part that decides whether an ERP integration succeeds is transaction discipline. Financial records must not be created twice because a retry fired, and they must not silently fail either. That means idempotency keys on every posting, a reconciliation report that finance actually reads, and a defined answer to what happens to an order that the ERP rejects on a validation rule the website did not know about.
CRM integration
CRM integrations look simpler and generate more arguments, because the CRM and the billing system usually disagree about what a customer is. Sales works with leads, accounts and opportunities; finance works with billable entities and legal names. One account in Salesforce or HubSpot can map to three billing records, or three accounts to one.
The flows are lead capture from the website, account and contact synchronisation, opportunity to order handoff, and billing or usage data flowing back so sales can see account health. Salesforce and HubSpot both have capable REST APIs and both have rate limits that matter at volume, so bulk operations belong in their batch interfaces rather than in a loop.
Resolve the identity question before writing anything. Decide what uniquely identifies a customer across systems, decide which system may create one, and decide which fields each side is allowed to overwrite. A field-level ownership table is unglamorous and prevents most of the support tickets that follow a CRM integration going live.
API design and development
Where you are exposing your own capability rather than consuming someone else's, the integration work becomes API design. That is a different discipline: resource modelling, authentication, pagination that still works on the hundredth page, filtering, versioning, and error bodies a client can act on programmatically rather than by reading prose.
We build these with an OpenAPI specification as the contract rather than as documentation written afterwards, because the specification is what lets a consumer start work before the implementation is finished. Versioning policy is decided at the start, since the cost of changing an API with unknown consumers is what makes teams afraid to change it at all. Authentication is usually OAuth 2.0 client credentials for server-to-server work, or signed tokens where a third party needs constrained access.
Read our position plainly: most internal APIs do not need GraphQL. It solves over-fetching for varied clients and introduces resolver-level query amplification that will take your database down the first time a consumer nests three levels. Where it is the right answer we build it with batching and depth limits from the start. Where REST is the right answer we say so.
Message queues and event-driven integration
Synchronous integration means your checkout is only as available as the slowest system it calls. Moving to messaging changes that: the order is accepted, an event is published, and the downstream systems consume it when they can.
RabbitMQ suits work queues and routing patterns; Kafka suits high-volume event streams and replay, and is over-specified for most mid-sized estates; managed options such as SQS and SNS or Azure Service Bus remove the operational burden. The choice matters less than the discipline around it. Consumers must be idempotent because at-least-once delivery is the norm. Poison messages need a dead-letter queue with alerting, not a silent retry loop. Event payloads need a schema and a compatibility policy, or you will not be able to change a producer without breaking a consumer you forgot about.
The trade-off is honest and worth stating: eventual consistency is genuinely harder to reason about and to debug than a synchronous call. It is the right choice when availability and throughput matter more than immediate consistency, and the wrong choice when a user is staring at a screen waiting for a definitive answer.
EDI and partner integration
EDI is old, still mandatory across retail, logistics, automotive and healthcare supply chains, and frequently the reason a project has a fixed external deadline. If a large retail customer requires EDI, the requirement is not negotiable and their specification governs.
The common document types are purchase orders, order acknowledgements, advance shipping notices, invoices and inventory advice, in X12 across North America and EDIFACT across Europe and Asia. Transport is AS2, SFTP or a value-added network. The work that consumes the time is not parsing the standard, it is that every trading partner implements it slightly differently, so each one needs its own mapping and its own certification cycle against their test environment.
Plan for the partner's timetable rather than yours. Certification queues are real and a partner's test window may be weeks out. We build EDI so that the mapping layer is separate from the transport layer, because the next partner will need a different map over the same pipe.
Data pipelines and warehouse integration
Reporting integration has a different tolerance for latency and a different bar for correctness. Nobody minds if the warehouse is an hour behind. Everybody minds if two dashboards disagree.
The work covers extracting from operational systems without degrading them, which usually means change-data-capture or an incremental watermark rather than a nightly full table scan; landing raw data before transforming it, so a transformation bug does not require re-extraction; transformations held in version control and tested; and a governed semantic layer so a metric has one definition. Where a system offers no clean extract, the integration map from phase one tells you which alternative is least fragile.
Keep operational integration and analytical integration separate. Using your reporting warehouse as the transport between two operational systems is a shortcut that turns a reporting outage into an order-processing outage.
How We Run an Integration Project
1. Map the estate
Every system, every existing exchange, the mechanism, the schedule and the owner at each end. Produced as a document you keep. This is usually where the project's real scope becomes visible, and where flows nobody remembered turn up.
2. Settle data ownership
One source of truth per entity, and field-level ownership where two systems both legitimately write. This is a business decision that we facilitate rather than make, and the project cannot be estimated honestly until it is closed.
3. Choose the pattern per flow
Synchronous API, asynchronous message, scheduled batch or EDI, decided per flow against its latency requirement and its failure tolerance. Some flows genuinely should stay as a nightly file, and we will say so rather than modernise for its own sake.
4. Build the highest-risk flow first
Not the easiest one. The first integration should prove the authentication, the error handling, the monitoring and the deployment path, so that the remaining flows are repetition rather than discovery.
5. Make failure visible
Monitoring on throughput and error rate, alerting on dead-letter depth, and a reconciliation report where money is involved. An integration that fails silently is worse than one that does not exist, because people trust it.
6. Hand over properly
The integration map updated, the OpenAPI specifications, the runbook for each alert, and the mapping documents per partner. Your team should be able to diagnose a failure at 2am without calling us, and add the next partner without us.
Where This Fits With Our Other Work
If you do not yet know which integrations you need, a technology roadmap engagement produces the estate map and the sequence first, and that is usually the cheaper order to do things in. Where the integration question is really an architecture question, enterprise architecture consulting covers target-state and governance in more depth.
On the build side, integration work on a PHP estate is handled by PHP developers with framework-specific experience, and API-heavy work by backend developers. Where the integration is a step toward reporting, data specialists pick up the warehouse and modelling side.
Frequently Asked Questions
What is enterprise integration?
Making separate business systems exchange data reliably: an ERP, a CRM, a warehouse system, a payment provider, a data warehouse. It covers the connection mechanism, the data mapping between systems that name the same thing differently, error handling when one side is unavailable, and deciding which system is the source of truth for each record. The hard part is rarely the connection. It is agreeing the data ownership.
Do we need an integration platform, or can we build point-to-point connections?
Below roughly five or six systems, well-built point-to-point connections are usually cheaper and simpler. Above that, the number of possible connections grows faster than your team can maintain them, and a hub or message broker starts paying for itself. Buying a platform before mapping the flows is the common expensive mistake: the tool does not make the data-ownership decisions for you.
How do you handle an integration when one system is down?
By assuming it will be. Messages go onto a durable queue rather than being fired and forgotten, retries use exponential backoff so a struggling system is not overwhelmed, and anything that exhausts its retries lands in a dead-letter queue a human is alerted about. Operations that could be delivered twice are made idempotent with a deduplication key, so a retry cannot create a second order or a second invoice.
Can you integrate legacy systems with no API?
Usually yes, and it is a large share of the work. Options in rough order of preference: an existing but undocumented API, read-only database access through a defined view, scheduled file exchange over SFTP, a vendor export or import utility, and screen automation as a last resort. Each has different failure modes. We document which one we used and why, because the choice constrains how the integration can evolve.
What does an enterprise integration project deliver?
An integration map of what talks to what and by which mechanism, a documented source of truth per data entity, the integrations themselves with retry and error handling built in, monitoring and alerting so failures are visible before a user reports them, and runbook documentation for the on-call path. Where API design is involved, an OpenAPI specification and a versioning policy.
How long does an enterprise integration project take?
A single well-understood integration between two systems with usable APIs is typically two to four weeks including testing. A programme covering an ERP, CRM and warehouse system with legacy components and disputed data ownership runs three to six months, and the discovery phase is where the honest estimate comes from. Anyone quoting a full programme before mapping your flows is guessing.