WeHub
Back to blogsThe preview of Why Multi-Tenant API Architecture Is a Must for NHS ESR Data post
ESR

Why Multi-Tenant API Architecture Is a Must for NHS ESR Data

NHS ESR data powers multiple organisations, teams, and vendors. Without multi-tenant API architecture, integrations become duplicated, insecure, and hard to govern. Here’s why multi-tenancy is essential—and how to implement it safely for ESR-to-API workflows.
WeHub
Reading time: ~9–11 min

The reality: ESR data is shared by many consumers

In the NHS, workforce data isn’t consumed by one system. It feeds onboarding and access workflows, rostering and bank staffing, HR reporting and finance alignment, supplier/vendor platforms, and internal dashboards and analytics.And the organisation structure is rarely “one clean boundary.” You may need to support:
  • multiple trusts
  • multiple sites and departments
  • partner organisations
  • shared services
  • vendor access with strict scoping
  • and varying policies across groups
If your architecture assumes “one tenant,” you’ll rebuild the same integration repeatedly—or centralise everything without proper boundaries (which becomes a security and governance nightmare).

What “multi-tenant” means for NHS ESR (practically)

Multi-tenant architecture means one platform instance can securely serve many organisational units (“tenants”) while keeping data and access properly separated.For ESR-to-API, that usually means:
  • each trust (or organisational entity) is a tenant
  • vendors/apps access only the tenant(s) they’re authorised for
  • rules can be shared globally but configured per tenant
  • audit trails and exceptions are tenant-aware
  • onboarding a new tenant is mostly configuration, not a rebuild
The key idea: one governed integration layer, many safely isolated tenants.

Why single-tenant ESR APIs fail at NHS scale

A single-tenant ESR API layer tends to produce one of two bad outcomes:1) Duplicate stacks everywhereEach trust/team spins up their own ingestion + mapping + validation + publishing. This multiplies cost and creates inconsistent rules.2) One shared stack with weak boundaries
  • vendors can see too much
  • audit is messy
  • mistakes become incidents
  • confidence drops
At NHS scale, both paths are expensive. Multi-tenancy is the way out.

The 7 must-have benefits of multi-tenant ESR APIs

1) Strong data isolation (by default)Tenants only access their own data. This is the non-negotiable baseline.2) Consistent rules across consumersValidation and integrity rules are applied centrally and uniformly.3) Faster onboarding of new trusts / org unitsOnboarding becomes “configure + deploy,” not “start a new integration project.”4) Safer vendor access
  • scope access to a tenant
  • scope access to endpoints/resources
  • enforce least-privilege permissions
5) Cleaner auditing and complianceEvery API call, exception, and transformation can be tracked per tenant: who accessed what, what changed, which file/record produced it, and what rules were applied.6) Easier change managementYou can roll out shared platform updates once, tenant-specific configs separately, and versioned APIs without breaking everyone.7) Lower total cost over timeYou pay once to build the capability, then scale it.

Tenant isolation models (and which one to pick)

There are 3 common models:Model A: Database-per-tenant
  • Pros: strongest isolation, clear blast radius
  • Cons: more operational overhead at scale
Model B: Schema-per-tenant (same database)
  • Pros: strong isolation with less overhead than DB-per-tenant
  • Cons: operational complexity with many tenants
Model C: Shared schema with tenant_id (row-level tenancy)
  • Pros: simplest operations, scales well
  • Cons: isolation must be enforced perfectly (RBAC + row-level security + query discipline)
Pragmatic recommendation: start with schema-per-tenant or row-level tenancy depending on your scale and risk profile. What matters most is enforcing isolation consistently in identity, data access, and audit.

Security essentials: identity, access, and audit

Multi-tenancy without strong security is just a shared database with extra steps.Minimum security requirements:1) Tenant-aware authenticationUse identity tokens that include tenant context (or map identities to tenants via your auth layer).2) Authorisation that enforces tenancyEvery request must be evaluated against tenant membership, role permissions, and endpoint/resource scope.3) Least-privilege vendor scopesVendors should never have “all tenant” access by default. Use scoped API keys / OAuth clients per tenant + per permission set.4) Tenant-aware audit logs
  • tenant_id
  • actor
  • resource
  • action
  • timestamp
  • correlation IDs (trace across workflows)
This is where multi-tenancy becomes defensible to security and governance teams.

Data contracts: versioning without chaos

In multi-tenant environments, breaking changes are expensive because many consumers depend on you.Good patterns:
  • version your APIs (/v1, /v2) or version your schemas explicitly
  • introduce changes behind feature flags per tenant
  • allow tenant-by-tenant rollout (pilot → expand)
  • keep backward compatibility windows
  • document contracts clearly
Multi-tenancy forces discipline—and that’s a good thing.

Tenancy-aware workflows: ingestion, validation, publishing

A multi-tenant ESR-to-API workflow should be tenant-aware from the first step:Step 1: Ingest (tenant identified early)
  • determine tenant from file source, connection, or metadata
  • store raw files with tenant context
  • track processing state per tenant
Step 2: Normalise + validate (rules applied per tenant)
  • shared baseline validations (global)
  • tenant-specific rules/configs (where needed)
  • position integrity checks
  • quarantine exceptions per tenant (with the right owners notified)
Step 3: Publish APIs/events (tenant scoped by default)
  • APIs are scoped by tenant automatically
  • events include tenant context
  • consumers can only subscribe/access what they’re allowed to
Step 4: Audit and observability
  • success/failure rates per tenant
  • exception rates per tenant
  • performance metrics per tenant
  • full lineage: tenant + file + record + output

Common mistakes (and how to avoid them)

Mistake 1: “We’ll add multi-tenancy later”Later becomes never—and by then, tenant boundaries are too expensive to retrofit. Build tenancy into the API contract and data model from day one.Mistake 2: Tenant isolation only at UI levelIf the backend doesn’t enforce tenancy, you don’t have multi-tenancy. Enforce tenancy in auth + data access + audit.Mistake 3: One vendor credential for everythingThis is how accidental data leaks happen. Use per-tenant credentials/scopes and rotate them.Mistake 4: No tenant-aware observabilityYou can’t operate what you can’t see. Track SLA, failures, and exceptions per tenant.

A reference blueprint (simple + scalable)

A clean reference setup looks like:
  • Tenant registry (tenant metadata, configs, feature flags)
  • Ingestion service (SFTP/file detection, tenant identification, raw storage)
  • Normalisation + rules engine (schemas, validations, integrity checks)
  • Publishing layer (REST APIs + event stream)
  • Audit + observability (logs, tracing, metrics, dashboards)
  • Access control (tenant-aware RBAC/ABAC, vendor scopes)
This is not overengineering. It’s the minimum for safe scale.

The bottom line

NHS ESR data naturally serves multiple organisations, teams, and vendors. If your ESR-to-API layer isn’t multi-tenant, you’ll pay in duplicated integrations, inconsistent rules, and growing security risk.Multi-tenant API architecture gives you:
  • tenant isolation by design
  • consistent validation and rules
  • safer vendor access
  • tenant-by-tenant rollout
  • scalable onboarding
  • clean auditing and observability
That’s why multi-tenancy isn’t a “nice-to-have.” It’s a must.

Keywords

ESRNHSMulti-Tenant ArchitectureAPIsData GovernanceSecurityIntegration
Why Multi-Tenant API Architecture Is a Must for NHS ESR Data | WeHub | Blog