Multi-tenant routing for SaaS APIs
Model host-based tenants, path-based tenants, and white-label ingress for B2B APIs—encode tenant context at the edge so handlers avoid giant conditional routers.
Last updated: 2026-06-28
Answer first
Direct answer
Multi-tenant routing for SaaS APIs. Encode tenant dimensions at the gateway so every handler receives normalized tenant context instead of re-deriving it from raw requests.
When it fits
- B2B SaaS APIs
- Per-customer webhook endpoints
Tradeoffs
- Giant routers with nested conditionals hide auth mistakes until an incident finds them for you.
- Copy-pasting a deployment per tenant does not scale operationally past the first handful of customers.
Workload and what breaks
Tenant leaks are expensive
A single shared stack with ad hoc tenant checks invites ID confusion, and ID confusion in a B2B API means data exposure.
Debugging “which tenant hit this?” without routing metadata slows every incident down at exactly the wrong moment.
Trade-offs
Anti-patterns to avoid
Giant routers with nested conditionals hide auth mistakes until an incident finds them for you.
Copy-pasting a deployment per tenant does not scale operationally past the first handful of customers.
How Inquir helps
Structured ingress for multi-tenant APIs
Encode tenant dimensions at the gateway so every handler receives normalized tenant context instead of re-deriving it from raw requests.
Reuse observability and configuration patterns across tenants without merging their runtime processes.
What you get
Multi-tenant routing patterns
Host-based tenants
Map customer subdomains to function sets.
Path prefixes
Keep one certificate while namespacing routes.
Auth separation
Attach different API key policies per surface when needed.
What to do next
How to implement multi-tenant routing on Inquir
Choose strategy
Use host-based routing for white-label/customer-facing endpoints; use path-based routing when DNS is constrained.
Normalize context
Pass tenant identifiers explicitly into handlers.
Test isolation
Automate negative tests that cross tenant boundaries.
Code example
Host-based and path-based tenant patterns
Host-based: acme.example.com → tenant slug from Host header. Path-based: example.com/t/acme/api → tenant slug from URL prefix. Both patterns normalise tenant context before handlers run.
export async function handler(event) { // acme.example.com → 'acme' const host = event.headers['host'] ?? event.headers['Host'] ?? ''; const tenantSlug = host.split('.')[0]; if (!tenantSlug) return { statusCode: 400, body: 'missing tenant' }; const payload = JSON.parse(event.body || '{}'); const data = await loadForTenant(tenantSlug, payload); return { statusCode: 200, body: JSON.stringify(data) }; }
export async function handler(event) { // /t/acme/api/orders → 'acme' const match = (event.rawPath ?? event.path ?? '').match(/^\/t\/([^/]+)/); const tenantSlug = match?.[1] ?? event.pathParameters?.tenant; if (!tenantSlug) return { statusCode: 400, body: 'missing tenant' }; const payload = JSON.parse(event.body || '{}'); const data = await loadForTenant(tenantSlug, payload); return { statusCode: 200, body: JSON.stringify(data) }; }
When it fits
When this matters
When this works
- B2B SaaS APIs
- Per-customer webhook endpoints
When to skip it
- Single-tenant internal tools
FAQ
FAQ
Does multi-tenant routing replace database row-level security?
No—ingress routing helps avoid cross-tenant mistakes at the edge; databases still need tenant-aware policies and tests.
Host-based vs path-based tenants—which to choose?
Hosts feel cleaner for white-label APIs; paths work when DNS is constrained—both can be valid if tenant context is explicit to handlers.
How do I test tenant isolation?
Automate negative tests: tokens from tenant A must never succeed against tenant B routes, and logs should tag tenant IDs consistently.