Appearance
Manulife Canada API landscape
| Source | client-resources/manulife-api-landscape 10.html |
| Type | Standalone interactive HTML — open it in a browser |
| Title | Manulife Canada — API Landscape · For KONRAD & UCX |
| Method | Live Azure Resource Manager enumeration plus Confluence architecture pages |
What it is
A consolidated, self-contained inventory of every documented production API across Manulife Canada, built from live ARM enumeration rather than from documentation. It was prepared for this engagement — the subtitle names Konrad explicitly — and it is the only artifact in the set that tells us what the integration estate actually contains rather than what a design says about it.
It is also, incidentally, evidence about the handoff format question: the client produced and sent a standalone interactive HTML artifact. See open questions, item 1.
The estate in numbers
| Gateways | 2 |
| API operations | ~4,200 |
| Business-unit tenants | 15+ |
Hub and spoke
Manulife Canada runs a hub-and-spoke API management strategy: one enterprise-grade multi-tenant Azure APIM serving most business units, and a dedicated instance for Group Benefits.
| PIE-APIM-CAC-PROD | GB-APIM-CAC-PROD | |
|---|---|---|
| Owner | Enterprise Technology Services | GB Platform |
| Model | Shared, multi-tenant | Dedicated |
| Operations | 2,889 across 579 APIs | 1,311 across 342 APIs |
| Region | canadacentral (Canada East DR twin) | canadacentral |
| External host | api.manulife.com | api.uat.gb.manulife.com (UAT mirror enumerated) |
Business units connect to the enterprise gateway as tenants with logical isolation — APIM products, subscription keys and ACLs. Group Benefits routes through its own instance because of the Akamai GTM flow and high-volume claims and member APIs. zOS Connect services are exposed through PIE-APIM as a mainframe adapter, not as a peer gateway.
Distribution by business unit
| Business unit | Operations |
|---|---|
| Group Benefits (both gateways) | 1,455 |
| Individual Insurance (IIC) | 1,075 |
| Common Tech + AI + IAM + Mobile (CTF) | 950 |
| Manulife Bank | 351 |
| Data Office + Marketing (CSDO) | 288 |
| Wealth (GWAM, MIM, Institutional) | 81 |
Individual Insurance is the largest tenant on the shared gateway; CTF supplies shared BPM, alerts, preferences and content services.
The call path
The artifact also draws the end-to-end path an external call takes: external consumer → Akamai → F5 GTM → Azure Application Gateway → APIM → microservices, databases, mainframe. Both gateways follow the same pattern with different hostnames. It closes with a combined searchable directory of every API across both gateways.
What it shows about identity
The directory is searchable, and searching it changes what "not in MVP scope" means. Several capabilities the ADS defers to later phases already exist as registered APIs:
| Capability | In the inventory as |
|---|---|
| OAuth 2.0 / OIDC gateway | ext-cdt-cet-iam-gateway-prod — /authorize, /token, /userinfo |
| ForgeRock identity management | ext-cdt-cet-di-can-idm-prod |
| BU Mapping Service | ext-cdt-cet-di-can-bu-mapping-prod — already in PROD, /mappings/search |
| Entitlements | int-cdt-cet-di-can-ent-api-*-prod, already split three ways by audience — advisor, customer portal, group benefits |
| Token exchange | gb-core-authx, described as an RFC 8693 OAuth token-exchange service in Group Benefits |
| Consent | ext-cdt-ctf-ois-can-pref-consent-v3-prod, a v3 preferences and consent API |
| Customer 360 / MDM | int-cdn-c360-mdm-can-*, ext-cdn-c360-mdm-can-customerhub-prod |
| Mobile authentication | ext-cdt-cet-mobile-can-oauth-prod — a separate OAuth stack from the web path |
Two of those rows carry disproportionate weight. Token exchange is the mechanism the segment assessment's condition 02 names as the remedy for B-01, and it is not a capability Manulife would be adopting for the first time — which is the basis of R1. And mobile authenticating through its own stack is estate-level corroboration that the channel split is structural rather than a scoping preference — see R3.
Read with the appropriate caution: the GB gateway was enumerated from UAT with PROD access pending, so a GB entry evidences that a service is registered, not that it is live in production.
Why it matters here
It is the evidence base for the integration and API architecture deliverable. SOW WS 2 names integration and API architecture as a target-state domain; this is the current state of it, enumerated rather than asserted.
It reframes the fan-out problem. The volumetry gap that both client reviews flag is not "we don't know what APIs exist" — the inventory is complete and machine-derived. It is that nobody has sized the traffic a unified shell puts through them. Those are different problems with different fixes, and the second is much cheaper once you have the first.
Wealth's 81 operations against Bank's 351 and IIC's 1,075 is worth a second look. Wealth is also the business unit the ADS says needs a net-new experience API, and the one gated behind FCC's 25 TPS. The thinness of the Wealth surface and the Wealth capacity constraint are probably the same fact.
Open questions raised
- The GB gateway was enumerated from UAT with PROD access pending. Has PROD enumeration completed, and does the shape hold?
- Which of the ~4,200 operations are actually on the unified homepage critical path? The experience map maps 42 of them.
- Are per-tenant rate limits and quotas configured today at the APIM layer, and what are they? This is the fastest available answer to the "no per-BU rate limits captured" finding.