Tenant isolation

Fanzava is a multi-tenant platform — many hubs run on the same global infrastructure. Tenant isolation ensures that your hub’s data is completely separated from every other hub, and that groups within your hub are scoped correctly to their members.

Database isolation

Every API request carries a hub_id context, validated by Worker middleware on every request. Database queries filter by hub_id at the ORM layer, and the middleware validates the filter is present and correct before any query reaches the database. The result:

• Every query is automatically scoped to your hub — it is architecturally impossible for a query in your hub to return data belonging to another hub
• The middleware validation step rejects any query missing or carrying an incorrect hub_id filter before the query executes

This isolation applies to participant profiles, tips, scores, groups, analytics, branding settings, and all other hub data.

Group-scoped isolation

Within a hub, groups provide an additional isolation boundary. Group-scoped data — group memberships, group leaderboards, group prizes, group analytics — is enforced at two layers:

• The group must belong to the hub. A query for group_id: X will only return data if X is a group in the hub of the requesting user.
• The user must be a member of the group. Where a participant is requesting group-scoped data, the middleware verifies their membership before the query executes.

This means a participant in Group A within a hub cannot access Group B’s leaderboard or membership unless they’re also a member of Group B. Hub admins can see all groups within their hub but cannot see groups in other hubs.

Authentication isolation

Participants authenticate to a specific hub. A user who is a participant in Hub A cannot access Hub B unless they’re separately invited and enrolled. Hub admin credentials are similarly scoped — being an admin in Hub A grants no access to Hub B.

For Enterprise hubs using SSO, the IdP connection itself is scoped to the hub. A user authenticating through your IdP can only land on your hub, not on other Fanzava hubs.

API isolation

Every API request is authenticated and carries the hub identity in the request context. The API layer enforces that authenticated users can only access endpoints relevant to their hub and their role within it. Cross-hub API calls are not possible from any participant or admin role.

Network and compute isolation

Fanzava’s compute layer (Cloudflare Workers) runs globally on shared infrastructure, with isolation enforced at the application and database layers as described above. This is the standard tenant-isolation model for serverless platforms — and is what the certifications of Fanzava’s underlying providers (Cloudflare, Neon) cover.

For Enterprise customers with specific regulatory or contractual requirements, Fanzava can provision dedicated compute resources with no shared runtime with other hubs. Contact your account manager to discuss whether dedicated infrastructure is appropriate for your deployment.

What is shared

The following platform-level services are shared across all hubs:

• Sports data feed ingestion — read-only, no hub data involved
• Email delivery infrastructure — your emails are sent through a shared sending pool, but your content and recipient lists are isolated
• CDN for static assets — logos and fonts are served via hashed URLs with no cross-hub discovery
• Global identity lookup — pseudonymised UUIDs and region pointers only (no PII), used to route requests to the correct regional database

None of these shared services have access to hub-specific participant data.

i

Note

Tenant isolation is one of Fanzava’s core architectural commitments. The hub_id filter and Worker middleware validation are applied to every database query without exception. Architectural review documentation is available to Enterprise customers under NDA on request.