EAOT
Patterns / Integration Architecture

API-Led Integration

Layered System, Process, and Experience APIs that turn point-to-point sprawl into reusable capability.

Channels
Experience APIs
Process APIs
System APIs
Systems of Record

Conceptual flow

Problem

Every new consumer triggers a bespoke interface to a system of record, multiplying cost and coupling with each project.

Context

Enterprises with a stable core (ERP, CRM, billing) and a growing number of digital channels that need the same data in different shapes.

Solution

Expose System APIs over each system of record, compose business logic in Process APIs, and shape channel-specific payloads in Experience APIs. Contracts are versioned and owned by the domain, not the project.

Benefits

  • Reuse across channels
  • Clear ownership boundaries
  • Predictable change impact
  • Faster onboarding of new consumers

Risks

  • Layer proliferation
  • Latency added per hop
  • Governance overhead if contracts drift

Trade-offs

  • Reuse over raw latency
  • Upfront design over project speed

When to use

  • Multiple consumers of the same core data
  • Request/response semantics dominate
  • Strong need for contract governance

When not to use

  • High-volume telemetry ingestion
  • Sub-100ms streaming requirements
  • A single consumer with a single system

Discuss this pattern

How have you applied it — and where did it break? Bring your experience to the community.

Open the discussion