Example 4 · API Framework Orchestration

New backend — loan balance (direct REST/JSON integration)

A channel asks: check the customer's loan balance — a brand-new capability, served by a brand-new loan servicing platform the bank has never connected to before. It bypasses the existing core middleware entirely. Audax integrates with it via configuration, because REST/JSON and Bearer auth are already-supported patterns.

  1. identifier lookup
  2. A new canonical endpoint, following the same profileId-scoped, token-based addressing pattern as the account endpoint. Same design, new resource type.

    GET /customer/v2/customers/{profileId}/loans/{loanToken}/balance
    
    {
      "profileId": "PTR0000000001",
      "loanToken": "a7c2e9f1-...",
      "loanAccountNumber": "LN-2024-008812",
      "loanType": "PERSONAL_LOAN",
      "loanStatus": "Active",
      "balance": {
        "outstandingPrincipal": 45000,
        "nextInstallmentAmount": 1200,
        "currency": "IDR"
      }
    }
    Lua orchestrationLua Orchestration

    routes to the new loan servicing platform

    request.messageType = "LOAN_BALANCE_INQUIRY"
    request.profileId   = account.profileId
    route_to("LOAN_SERVICING_PLATFORM")
    Egress transformation → loan platform JSONTransformation

    canonical request rendered into the loan platform's REST contract — JSON, not XML.

    POST https://loan-platform.example/api/v1/loans/balance
    Authorization: Bearer <service-token>
    Content-Type: application/json
    
    {
      "loan_ref": "a7c2e9f1-...",
      "customer_ref": "PTR0000000001"
    }
    Loan servicing platformnew backend — REST/JSON

    A new loan servicing platform — separate from the core banking middleware. Exposes its own REST/JSON API.

    {
      "status": "success",
      "loan": {
        "account_number": "LN-2024-008812",
        "product": "PERSONAL_LOAN",
        "state": "ACTIVE",
        "outstanding_balance": 45000,
        "next_payment": 1200,
        "currency": "IDR"
      }
    }
    Response transformationCanonical / Core

    Loan platform JSON → canonical shape shown above. Field renames (outstanding_balance → balance.outstandingPrincipal, next_payment → balance.nextInstallmentAmount) and a value mapping (state "ACTIVE" → loanStatus "Active") — same mapping engine as the XML path, applied to JSON instead.

    Account balance (Ex 1–3)Loan balance (this example)
    BackendCore banking middlewareNew loan servicing platform
    Transport / formatHTTP + XMLHTTP + JSON
    AuthInternal service authOAuth2 Bearer (already supported)
    New connector code?No — REST/JSON + Bearer already supported

The pattern: check loan balance is a brand-new capability, served by a brand-new backend the bank just introduced — and it's still configuration. A new canonical endpoint (same addressing pattern as accounts), a new egress mapping (canonical → this platform's REST/JSON contract), and a new service registration. No new connector code, because REST/JSON and Bearer auth are already-supported patterns. This is what integrate once, deliver everywhere looks like when everywhere includes systems the bank adds after go-live. Together, Examples 1–4 show: open finance standards converge on one canonical core (1), the bank's own channels use the same core (2), new data flows through with one config line (3), and entirely new backends — even ones bypassing existing middleware — are configuration too, as long as the transport is one Audax already speaks (4).