Multi-tenancy

NShop is multi-tenant from the ground up. One install runs many stores; each is isolated in catalog, orders, branding, payouts, and team — but all share the same customer identity.

Three layers of isolation

Tenant safety is enforced by three independent layers. None of them trust each other; a bug in one is caught by the next.

1. Request-time tenant resolution — the middleware parses the subdomain off Host and writes an x-tenant header on every request. Server code reads that header through getTenantSlug() — never the raw host.
2. Auth custom claims — Firebase Auth users carry a tenantId claim (for tenant admins) or a superadmin: true claim. Every mutating API route re-verifies the claim against the request's tenant.
3. Firestore security rules — the data model is locked at the database. Even if a route forgot to check, the rule would refuse the write.

Each layer alone would be enough most of the time. Together, a slip in one is caught by the others.

What's in this section

• Tenants and domains — subdomains, custom domains, tenant resolution.
• Roles — customer, tenant admin, superadmin.
• Isolation — exactly which data is shared and which isn't.
• Superadmin — the global, read- only operator role.