Enterprise Application Integration: Connecting Your Tech Stack

The average mid-market company runs 110+ SaaS applications. The average enterprise runs 900+. And almost none of them talk to each other properly. We've seen companies where salespeople manually copy deal data from their CRM into spreadsheets, then email those spreadsheets to finance for invoicing. In 2026. The technology to connect these systems has existed for years — the problem is knowing which integration approach fits which situation.

The Integration Landscape in 2026

Enterprise integration has shifted dramatically. Ten years ago, it meant ESBs (Enterprise Service Buses), XML transformations, and six-figure middleware licenses. Now it's APIs, webhooks, iPaaS platforms, and event streams. The tools are better and cheaper, but the architecture decisions are harder because there are more options.

Here's what a typical mid-market tech stack looks like — and why integration matters:

Without integration, each of these systems becomes a data silo. Your sales team doesn't know a customer has an open support ticket. Your finance team doesn't know which projects have been delivered. Your warehouse doesn't know about orders placed on the website. It's not a technology failure — it's an architecture gap.

Core Integration Patterns

Every integration you'll ever build follows one of four patterns. Understanding these is more important than knowing any specific tool, because tools change — patterns don't.

Pattern 1: Point-to-Point (Direct API Calls)

System A calls System B's API directly. Simple, fast to build, and perfectly fine when you have 2-3 integrations.

// Example: CRM → Accounting (direct API call)
// When a deal closes in CRM, create an invoice in accounting

async function onDealClosed(deal) {
  const invoice = {
    customer_id: deal.customer.accounting_id,
    amount: deal.value,
    line_items: deal.products.map(p => ({
      description: p.name,
      quantity: p.qty,
      unit_price: p.price
    })),
    due_date: addDays(new Date(), 30)
  };

  await accountingAPI.post('/invoices', invoice);
  await crmAPI.patch(`/deals/${deal.id}`, {
    invoice_created: true
  });
}

The problem with point-to-point: it doesn't scale. With 5 systems, you need up to 10 connections. With 10 systems, up to 45. With 20 systems, up to 190. This is how you end up with spaghetti architecture — every system tightly coupled to every other system, and nobody remembers which integrations exist.

Pattern 2: Hub-and-Spoke (Middleware / iPaaS)

A central hub handles all integrations. Each system connects only to the hub, not to each other. This is what iPaaS platforms like MuleSoft, Workato, and Make.com provide.

With 20 systems, you need 20 connections instead of 190. Adding a new system means one new connection, not nineteen. This is the right pattern for most mid-market companies with 8+ systems to integrate.

Pattern 3: Event-Driven (Pub/Sub)

Systems publish events to a message broker. Other systems subscribe to the events they care about. No system knows about any other system — they only know about events.

// Producer: Order Service publishes event
await messageBroker.publish('orders', {
  event: 'order.placed',
  data: {
    order_id: 'ORD-2847',
    customer_id: 'CUST-391',
    items: [...],
    total: 4250.00
  },
  timestamp: new Date().toISOString()
});

// Consumer 1: Inventory Service (reduces stock)
messageBroker.subscribe('orders', 'order.placed', async (event) => {
  for (const item of event.data.items) {
    await inventory.reduceStock(item.sku, item.quantity);
  }
});

// Consumer 2: Notification Service (sends confirmation)
messageBroker.subscribe('orders', 'order.placed', async (event) => {
  await email.send(event.data.customer_id, 'order-confirmation', event.data);
});

// Consumer 3: Analytics (tracks revenue)
messageBroker.subscribe('orders', 'order.placed', async (event) => {
  await analytics.trackRevenue(event.data.total, event.data.items);
});

Event-driven architecture is the most scalable pattern, but it's also the most complex to implement and debug. We recommend it when you have high-volume data flows, need real-time processing, or have systems that need to react to the same event differently.

Pattern 4: Data Synchronization (ETL/ELT)

Batch or near-real-time synchronization of data between systems, usually through an intermediate data store. This isn't glamorous, but it solves 80% of integration needs: "I need the same customer list in CRM and accounting."

iPaaS vs Custom Integration: The Decision That Matters Most

This is the question every CTO asks us. The answer depends on what you're connecting and how much control you need.

Our recommendation for most mid-market companies: iPaaS for SaaS-to-SaaS connectivity, custom code for anything involving your own applications. This hybrid approach gives you speed where connectors exist and control where they don't.

Building an API-First Integration Strategy

Regardless of which pattern or tool you choose, the foundation of modern integration is APIs. An API-first strategy means every system — including your custom applications — exposes data through well-documented APIs before anyone builds integrations.

API Design Principles for Integration

We've built and consumed hundreds of APIs across client projects. These principles have saved us the most rework:

1. Use REST for CRUD, webhooks for events. Don't force real-time notifications through polling REST endpoints. If your CRM needs to know when an invoice is paid, the accounting system should push a webhook — not get polled every 30 seconds.
2. Version from day one. /api/v1/customers not /api/customers. You will change your API. Make it painless.
3. Return consistent error formats. Every API should return errors in the same structure. Integrations that handle 15 different error formats are fragile.
4. Implement idempotency. Integration retries are inevitable. If creating an invoice is called twice with the same idempotency key, it should create one invoice — not two.
5. Paginate everything. An endpoint that returns 50,000 records in one response will break someone's integration at 3 AM.
6. Log every API call. When (not if) an integration fails, you need to know what was sent and received. We log request/response pairs with correlation IDs for every integration endpoint.

Webhook Best Practices

Webhooks are the backbone of real-time integration, but they're surprisingly easy to get wrong:

// Webhook receiver pattern we use
// Key: acknowledge immediately, process asynchronously

app.post('/webhooks/crm/deal-closed', async (req, res) => {
  // 1. Verify signature (CRITICAL for security)
  if (!verifyWebhookSignature(req)) {
    return res.status(401).json({ error: 'Invalid signature' });
  }

  // 2. Store the event (don't process inline)
  await eventQueue.enqueue({
    source: 'crm',
    event: 'deal.closed',
    payload: req.body,
    received_at: new Date()
  });

  // 3. Respond immediately (under 3 seconds)
  res.status(200).json({ received: true });

  // Processing happens asynchronously via queue worker
  // This prevents timeouts and allows retries
});

The most common webhook mistake: processing the event synchronously in the webhook handler. If your handler takes 10 seconds and the sender has a 5-second timeout, the sender will retry — and you'll process the event twice. Always acknowledge immediately, queue for processing.

Event-Driven Architecture for Integration

When point-to-point APIs and iPaaS aren't enough — usually because you need multiple systems to react to the same business event in real time — event-driven architecture is the answer.

Choosing a Message Broker

For most mid-market integration projects, we recommend RabbitMQ or AWS SQS/SNS. Kafka is powerful but operationally heavy — don't use it unless you're processing millions of events daily. We've seen companies adopt Kafka for 500 events/day, then spend more time maintaining Kafka than building features.

Event Design That Doesn't Break

Bad event design is the #1 cause of integration failures in event-driven systems. An event should be:

• Self-contained: Include all data the consumer needs. Don't force consumers to call back to the producer for details.
• Immutable: Once published, an event never changes. If the data changes, publish a new event.
• Versioned: order.placed.v2 — because event schemas evolve and consumers upgrade at different speeds.
• Named as past-tense facts: order.placed, payment.received, customer.updated — not create.order or process.payment. Events describe what happened, not what should happen.

Common Integration Scenarios We Build

These are the integration projects that come up in almost every engagement. Each one looks simple on paper and has hidden complexity.

CRM → ERP: The Deal-to-Invoice Pipeline

When a deal closes in the CRM, an invoice should appear in the ERP. Sounds simple. Here's what actually happens:

1. CRM customer doesn't exist in ERP → need to create or match first
2. CRM product names don't match ERP product codes → need a mapping table
3. CRM deal has custom pricing that doesn't fit ERP's pricing model → need transformation logic
4. CRM deal closes on Saturday but ERP only processes invoices on business days → need a queue
5. Someone re-opens the deal in CRM after the invoice was created → need conflict resolution

The integration itself takes a week. Handling edge cases takes three weeks. Budget accordingly.

E-commerce → Warehouse: Order Fulfillment

Order placed on website → warehouse picks, packs, ships → tracking number flows back to customer. The critical requirement: this must be near-real-time. A customer who places an order at 2 PM expects it to be in the fulfillment queue by 2:01 PM, not batched at midnight.

We use webhooks from the e-commerce platform to trigger order creation in the WMS (Warehouse Management System), with a dead-letter queue for failed deliveries. Every order that fails integration gets flagged for manual review — because a lost order is worse than a delayed one.

HR → Everything: Employee Lifecycle

New hire joins → accounts created in email, Slack, Jira, project management, payroll systems. Employee leaves → all access revoked within 4 hours (compliance requirement for most frameworks). This integration touches 8-15 systems and is the one most companies get wrong because it's built ad hoc over years.

Integration Mistakes We Keep Seeing

After building integrations for dozens of clients, these are the patterns that cause the most pain:

A Real Integration Audit

We recently audited a 40-person e-commerce company that had grown through acquisition. They had 3 Shopify stores, 2 warehouse systems, Xero for accounting, HubSpot for CRM, and 14 Zapier workflows connecting everything. The result:

• 4 of the 14 Zapier workflows had silently broken (API changes, expired auth tokens)
• Inventory counts were wrong in 2 of 3 stores because sync ran every 15 minutes but orders came in every 2 minutes during sales
• Customer data was duplicated across HubSpot and Xero with no master record — 23% of customers had mismatched email addresses between systems
• The finance team spent 8 hours/week manually reconciling orders against invoices

We replaced the 14 Zapier workflows with a Workato-based hub-and-spoke architecture (7 recipes) plus one custom Node.js service for real-time inventory sync. Cost: $1,200/month for Workato + the custom service. Savings: 32 hours/week of manual work across sales, warehouse, and finance teams. The integration paid for itself in 6 weeks.

Frequently Asked Questions