Business Context
A multi-tenant SaaS web application needed to participate in user journeys that continued into APIs hosted by the ISV as a separate single-tenant deployment for each customer. The web experience was shared, but each downstream service retained a customer-specific endpoint, identity relationship, availability boundary and operational context.
Direct browser access to those endpoints would have exposed routing knowledge to the client and made consistent protection, observability and onboarding difficult. The integration needed one governed entry path that could preserve tenant isolation, direct a request to the correct customer service and prevent a caller from selecting another tenant’s backend.
Goal
Expose customer APIs without weakening tenant boundaries
The goal was to give the SaaS application a consistent API surface while retaining the ownership and isolation of each customer deployment. Requests needed to be authenticated, associated with a trusted tenant identity and routed through governed configuration rather than an endpoint supplied by the browser.
The design also needed clear operational behaviour: edge protection, health visibility, route ownership, controlled customer onboarding and enough telemetry to distinguish a shared service problem from a customer-specific API failure.
Method
Use Front Door at the edge and APIM for trusted routing
Azure Front Door provided the public edge for the shared experience. Its global entry point, TLS handling, Web Application Firewall policies, health probing and origin-routing capabilities created a consistent protection and observability layer before traffic reached the application and API platform. Origin configuration limited the paths by which the hosted services were expected to receive traffic.
Azure API Management formed the tenant-routing boundary. Once the request had passed through the governed Front Door and APIM authentication and access-policy path, APIM resolved the trusted tenant relationship against server-side configuration and selected the corresponding ISV-hosted customer deployment. The client used a stable SaaS API contract and did not receive a catalogue of endpoint addresses.
The policy chain also provided a consistent place for request shaping, API version handling, throttling, correlation and diagnostic context. Backend authentication and customer-specific configuration remained controlled integration concerns, allowing each single-tenant API deployment to retain its own security boundary without spreading those differences throughout the SaaS application.
Customer onboarding treated routing as governed configuration. A new route required an owned tenant mapping, an approved endpoint, an established trust relationship, health checks and an operational support path. Front Door and APIM telemetry then provided evidence about edge traffic, policy failures, route health and customer-specific service behaviour.
Technical Challenges
Keep shared infrastructure from becoming shared trust
The most important risk was cross-tenant routing. A syntactically valid request was not sufficient: the tenant represented by the authenticated context had to match the backend selected by APIM. Route resolution, token validation and application permissions therefore had to describe the same tenant relationship.
The failure model was also distributed. Front Door, the SaaS application, APIM, tenant configuration and an ISV-hosted customer API could each affect a request. Correlation and health evidence were required to locate faults without exposing one customer’s operational information to another or treating every backend issue as a failure of the shared SaaS service.
Operational boundaries mattered even though the ISV hosted the whole service. The shared edge and routing platform had different release, configuration and failure characteristics from the customer-dedicated API deployments. Certificate or identity changes, API versions and endpoint availability therefore needed explicit ownership and a controlled onboarding and change process.
Outcomes
One SaaS experience could reach isolated customer deployments
The multi-tenant web application gained a stable route to multiple ISV-hosted single-tenant APIs without exposing backend selection to the browser. Front Door protected and observed the shared edge, while APIM selected the backend associated with the trusted tenant context.
Each customer API remained a distinct single-tenant deployment. New endpoints could be introduced through a repeatable configuration and assurance process, and operational evidence could distinguish edge, policy, routing and customer-specific service failures.
Business benefits
Extend SaaS journeys while preserving tenant isolation
- A consistent, protected API entry path for the multi-tenant SaaS application.
- Customer endpoints kept out of browser-controlled routing decisions.
- Tenant-aware backend selection derived from validated identity.
- Front Door WAF, TLS, health and routing capabilities applied at the shared edge.
- API policy, throttling, versioning and diagnostics centralised in APIM.
- Separate ISV-hosted single-tenant API deployments retained for each customer.
- Repeatable onboarding with explicit mapping, trust and support ownership.
Architecture value
Architecture made the trust boundary operable
The integration crossed organisational, tenant and operational boundaries. Architecture separated global edge concerns from API policy and customer service ownership, then connected identity, routing configuration and telemetry so that the correct backend could be selected, supported and changed without weakening isolation.
Discuss your project
Connecting SaaS to customer-dedicated services?
If a shared application needs to reach tenant-specific APIs, contact me to discuss the identity, edge protection, routing, ownership and operational evidence required for a secure integration model.
Contact me about an integration project