Custom Software for Complex Enterprise Integrations

Complex enterprise integration is rarely hard because of the protocol. It is hard because the systems disagree: two sources of truth for the same customer, an ERP that batches overnight while the web app expects real time, and a partner whose API rate limits are undocumented. Custom software earns its cost here by absorbing that disagreement rather than passing it to users. Parallel Loop's enterprise solutions practice exists for exactly this work.

TL;DR

• Integration cost is driven by data quality and system behaviour, not by the number of endpoints.
• Decide the source of truth per entity before writing code. Most integration failures are ownership disputes in disguise.
• Choose the pattern deliberately: point to point, hub and spoke, event driven, or batch file exchange.
• Design for partial failure from day one: idempotency, retries with backoff, dead letter queues and reconciliation.
• Observability is not optional. If you cannot see a failed sync within minutes, your users will find it before you do.

Decide the source of truth before you write code

For every shared entity, customer, product, order, invoice, one system must own it and the others must accept its version. When two systems both believe they own the customer record, you get silent overwrites, duplicate records and a support queue nobody can close. Write the ownership map during discovery and have both technical teams sign it. It is the highest-value hour of the project.

The four integration patterns, and when to use each

Protocols you will actually meet in enterprise work

• REST with JSON, usually with OAuth 2.0 client credentials. The modern default and the cheapest to integrate.
• SOAP with WSDL, still common in older ERP and finance systems. Verbose but predictable once mapped.
• EDI over AS2 or SFTP, using ANSI X12 in North America and EDIFACT internationally. Standard in logistics and retail supply chains.
• Webhooks for inbound events, which require a public endpoint, signature verification and replay protection.
• Database level or file exports for systems with no API, which need extra care around consistency and access control.

Design for failure, because failure is the normal case

1. Idempotency. Every write should carry a key so a retried request cannot create a duplicate order or double-charge an account.
2. Retries with exponential backoff and jitter, plus a cap. Aggressive retries against a struggling partner turn a small incident into an outage.
3. A dead letter queue for messages that fail repeatedly, with an interface that lets an operator inspect, correct and replay them.
4. Reconciliation jobs that compare both systems on a schedule and report drift, because silent divergence is worse than a visible error.
5. Circuit breakers so one failing dependency cannot exhaust your workers and take the whole application down.

What drives integration cost

Observability that prevents support tickets

Every integration should expose four things: a live view of sync status per system, a searchable log of individual message outcomes, alerting when the failure rate or queue depth crosses a threshold, and a manual replay control for operations staff. Where record volumes are high, a proper data pipeline engineering layer handles the throughput. Teams that build this find problems in minutes. Teams that skip it learn about problems from the customer, which costs more in trust than the feature cost to build.

How Parallel Loop approaches integration builds

Integration work runs through our custom integrations and API integration services practices as part of our B2B software development services, and it shows up in real builds: the Cleon1 B2B lead enrichment platform integrates enrichment workflows with CRM systems for sales teams, and our ecommerce work, including integrating Shopify with external ERP systems, regularly synchronises marketplace, ERP and warehouse systems where a missed order has a direct financial cost. The approach is the same each time: agree ownership, choose the pattern deliberately, design for partial failure, then make the whole thing observable.

Frequently Asked Questions

What makes enterprise integrations complex?

Not the protocol, but the disagreement between systems: two sources of truth for the same entity, mismatched update frequencies, inconsistent identifiers and undocumented behaviour under load. Complexity also comes from the organisational side, where each system has a different owner with different priorities and release cycles.

Should we build point to point or use an integration layer?

Point to point is fine for two or three systems with stable requirements. Once you reach four or more, or once several systems need the same transformations, a hub or integration layer reduces duplication and makes changes safer. The trade-off is that the hub becomes critical infrastructure that needs its own monitoring and resilience.

How do you prevent duplicate records across systems?

Use idempotency keys on every write so retries cannot create duplicates, agree a single source of truth per entity, and use stable external identifiers rather than matching on names or emails. Add a reconciliation job that compares both systems on a schedule and reports drift before users notice it.

Do we still need EDI in 2026?

In logistics, retail and healthcare supply chains, yes. Many large trading partners still exchange ANSI X12 or EDIFACT documents over AS2 or SFTP, and refusing to support that can exclude you from a contract. Modern builds typically translate EDI at the edge and use JSON internally.

How long does an enterprise integration take to build?

A well-documented REST integration with a sandbox can be a matter of days. A legacy system without a test environment, with poor data quality and a slow partner contact, can take weeks for the same volume of records. Estimate integrations individually rather than as a single line item.

What is the right way to handle a partner API going down?

Queue outbound work rather than failing user actions, retry with exponential backoff and a cap, open a circuit breaker after repeated failures so workers are not exhausted, and surface the degraded state in the interface. Then reconcile once the partner recovers, so nothing is silently lost.

Who should own integration credentials?

Your organisation, stored in a managed secret store such as AWS Secrets Manager, with access granted to the build team rather than credentials owned personally. Rotate on a schedule and after any team change. This is a frequent finding in security reviews.

Can integrations be added after the main build?

Yes, provided the architecture anticipated them: a clear domain model, stable internal identifiers and an isolation layer between your core logic and external systems. Integrations retrofitted into code with vendor-specific assumptions scattered through it are far more expensive.

Have an integration that keeps breaking?

Book a free 30 minute call. Bring the systems and the symptoms, and we will map the ownership model and the failure points before quoting anything.