Example 3 · API Framework Orchestration

New field, existing service — configuration only

The bank's core team adds overdraftLimit to the existing balance middleware. Audax exposes the new field through the canonical layer and out to every channel with a one-line change to the egress mapping config — no code, no redeployment.

Steps 1–3 are identical in both states. Only the canonical response (step 4) and the rendered external response (step 5) gain the new field — and only because a single line was added to the egress mapping.

  1. identifier lookup
  2. The bank's core team has added a new <OverdraftLimit> field to the middleware response. The canonical schema now surfaces it as overdraftLimit — produced by a single new line in the egress mapping config. No transformation code was changed.

    GET /customer/v2/customers/{profileId}/accounts/{accountToken}
    
    {
      "profileId": "PTR0000000001",
      "accountId": "02000103664-121-ID-IDR-1",
      "accountNumber": "70000600503",
      "accountCurrency": "IDR",
      "accountStatus": "Active",
      "balance": {
        "availableBalance": 1000,
        "ledgerBalance": 2000
      },
      "overdraftLimit": 500
    }

The pattern: new data from middleware flows through automatically once a single mapping line is added — the canonical service, gateway, and identifier resolution (steps 1–3) are completely unaffected. Example 4 shows the same configuration-only pattern for new error codes; Example 5 shows the one case that does require new code — a new connector.