MuleSoft API-Led Connectivity

The Problem It Solves

Enterprise integration without an architecture degrades into a spaghetti of direct point-to-point connections. System A calls System B directly. System C calls System B directly. System D needs System B data and calls it a third way. When System B changes, every caller breaks. When a new consumer needs the same data, it builds another direct connection. The integration estate becomes brittle, expensive to change, and impossible to govern.

API-led connectivity replaces point-to-point connections with a layered API network. Each layer has one job. Consumers depend on the layer above them, never on the system below.

The Three-Layer Architecture

%%{init:{'theme':'base','themeVariables':{'fontSize':'14px','fontFamily':'IBM Plex Sans, system-ui, sans-serif','primaryColor':'#DBEAFE','primaryTextColor':'#1e3a5f','primaryBorderColor':'#2563EB','lineColor':'#374151','clusterBkg':'#F9FAFB','clusterBorder':'#D1D5DB','edgeLabelBackground':'#FFFFFF'},'flowchart':{'curve':'orthogonal','padding':30,'nodeSpacing':65,'rankSpacing':75,'useMaxWidth':true}}}%%
flowchart TD
    subgraph EXP["Experience Layer — Shaped per Consumer"]
        E1[Mobile Banking API\nField selection, pagination\nLow payload, offline-friendly]
        E2[Web Portal API\nRich data, computed fields\nSession and preference aware]
        E3[Partner API\nContractual format\nVersioned, rate-limited]
    end

    subgraph PROC["Process Layer — Business Capability Orchestration"]
        P1[Account Onboarding Process\nOrchestrate KYC, Core Banking, CRM\nBusiness rules and error handling]
        P2[Payment Processing\nOrchestrate validation, authorisation\nFraud check, settlement]
        P3[Customer 360 Process\nAggregate from CRM, Core, Comms\nSingle view assembly]
    end

    subgraph SYS["System Layer — Data Source Abstraction"]
        S1[Core Banking System API\nHides SOAP/ISO8583 complexity\nNormalised data model]
        S2[CRM System API\nHides Salesforce specifics\nCanonical customer model]
        S3[KYC System API\nHides vendor API\nStandardised identity model]
        S4[Fraud System API\nHides proprietary API\nBoolean risk decision output]
    end

    subgraph SYSTEMS["Backend Systems"]
        BS1[Core Banking\nFIS, Temenos, Finacle]
        BS2[Salesforce CRM]
        BS3[KYC Vendor\nOmnicom, Jumio]
        BS4[Fraud Engine\nCustom or vendor]
    end

    E1 & E2 & E3 --> P1 & P2 & P3
    P1 --> S1 & S2 & S3
    P2 --> S1 & S4
    P3 --> S1 & S2
    S1 --> BS1
    S2 --> BS2
    S3 --> BS3
    S4 --> BS4

    style E1 fill:#BFDBFE,stroke:#2563EB
    style E2 fill:#BFDBFE,stroke:#2563EB
    style E3 fill:#BFDBFE,stroke:#2563EB
    style P1 fill:#BBF7D0,stroke:#16A34A
    style P2 fill:#BBF7D0,stroke:#16A34A
    style P3 fill:#BBF7D0,stroke:#16A34A
    style S1 fill:#FDE68A,stroke:#CA8A04
    style S2 fill:#FDE68A,stroke:#CA8A04
    style S3 fill:#FDE68A,stroke:#CA8A04
    style S4 fill:#FDE68A,stroke:#CA8A04

Layer Responsibilities

System APIs — Unlock Data Sources

System APIs wrap backend systems with a consistent, technology-agnostic interface. The backend system's protocol — SOAP, ISO 8583, proprietary binary, flat file — is hidden behind a REST or GraphQL API. The canonical data model exposed by the System API is designed by the integration team, not inherited from the backend.

A Core Banking System API exposes accounts, transactions, and customers in a canonical JSON model. Whether the backend uses FIS, Temenos, or Finacle is irrelevant to any caller above. When the bank migrates from one core to another, only the System API changes. The Process and Experience layers see no disruption.

System APIs are the most stable layer. They change only when the underlying system changes. They are published to Anypoint Exchange and versioned. They are tested independently of the processes that call them.

Process APIs — Encode Business Capabilities

Process APIs orchestrate System APIs to execute a business capability. They contain the business logic — the sequence of calls, the conditional routing, the error compensation, the data aggregation. They do not know about the consumers above them or the backend systems below them. They call System APIs only.

An Account Onboarding Process API orchestrates four System APIs: KYC verification, core banking account creation, CRM customer record creation, and notification dispatch. If KYC fails, the process returns a rejection. If core banking succeeds but CRM fails, the process executes a compensating transaction to reverse the account creation — a saga pattern implemented in the Process layer.

Process APIs are medium stability. They change when business rules change. They are the layer where Ascendion delivery teams spend most of their implementation effort on client engagements.

Experience APIs — Serve Specific Consumers

Experience APIs consume Process APIs and shape the response for a specific consumer. A mobile banking Experience API returns a compact account summary — balance, last five transactions, pending alerts — in a single call. A web portal Experience API returns the same data plus computed fields, extended history, and preference settings. A partner Experience API returns a contractually defined format regardless of how the internal model evolves.

Experience APIs contain no business logic. They perform field selection, format conversion, pagination, and consumer-specific error messaging. When the mobile app changes its data requirements, only the mobile Experience API changes — the Process and System layers are untouched.

Reusability Through Anypoint Exchange

Anypoint Exchange is the internal marketplace where System and Process APIs are published. A System API for Salesforce built for one project is available to every project. A Customer 360 Process API built for a banking client is adaptable for an insurance client. Templates, connectors, and DataWeave modules are all exchange assets.

The return on investment from API-led connectivity materialises through reuse. A new project that needs Salesforce access consumes the existing System API from Exchange rather than building another direct Salesforce integration. The reuse metric — percentage of Process APIs built from existing Exchange assets — is the leading indicator of integration estate maturity.

Application to Ascendion Engagements

API-led connectivity maps directly to the architecture decisions in Ascendion's financial services and healthcare engagements.

Banking: Core banking, CRM, KYC, and fraud systems are each wrapped in System APIs. Account opening, payment processing, and limit management are each a Process API. The mobile banking app, the web portal, and the open banking partner channel each have a dedicated Experience API. When a client migrates from one core banking vendor to another, the System API is the only integration asset that changes.

Healthcare: Electronic Health Record (EHR) systems, lab systems, and payer systems are System APIs. Clinical workflow orchestration — admit, transfer, discharge — is a Process API. The clinician portal, the patient app, and the insurance portal each have dedicated Experience APIs. HL7 FHIR normalisation happens at the System layer.

When to Use API-Led Connectivity

• Enterprise environments with multiple backend systems that multiple consumers need to reach
• Organisations planning incremental modernisation — System APIs abstract legacy systems while Process APIs reflect the new business model
• Clients with a multi-year integration roadmap where reusability across projects is a financial priority
• Regulated industries where auditability of integration flows and API governance are requirements

When a Simpler Approach Is Sufficient

• Two-system point-to-point integrations with no reuse requirement
• Small projects with short timelines where the three-layer overhead is not justified
• Greenfield microservices environments where each service exposes its own API directly

Anti-Patterns to Avoid

Flowchart

References

1. MuleSoft — API-Led Connectivity White Paper. mulesoft.com/resources/api/api-led-connectivity
2. MuleSoft — Anypoint Exchange. anypoint.mulesoft.com/exchange
3. Ross, Jeanne — Enterprise Architecture as Strategy. Harvard Business Review Press, 2006.
4. Richardson, Chris — Microservices Patterns. Manning, 2018.