How Retenza Keeps Every Store's Data Isolated

Why Data Isolation Is Non-Negotiable in Multi-Tenant SaaS

When you build a SaaS platform that serves hundreds — or thousands — of Shopify merchants, every tenant shares the same infrastructure: the same database clusters, the same application servers, the same API layer. That's the economic reality of multi-tenancy, and it's what makes SaaS affordable at scale. But it introduces a serious engineering obligation: no merchant should ever be able to see, touch, or accidentally receive another merchant's data.

This isn't just a best-practice concern. For platforms that handle customer emails, order details, and personally identifiable information (PII), the stakes are legal. GDPR Article 5 requires that personal data be processed with "appropriate technical measures" to ensure integrity and confidentiality. A data leak between tenants isn't just embarrassing — it's a regulatory incident.

At Retenza, we thought hard about how to architect isolation from day one. Here's how we did it.

The Foundation: organizationId Scoping on Every Record

The simplest and most effective isolation primitive in a shared-database, shared-schema architecture is consistent, mandatory tenant scoping on every database record. In Retenza's data model, every entity — conversations, email drafts, order snapshots, agent assignments, audit logs — carries an organizationId field that maps directly to the Shopify store that owns it.

This sounds straightforward, but the discipline required to enforce it consistently is significant. A few principles we follow:

• No unscoped queries allowed. Every database query that touches tenant-owned data must include an organizationId predicate. We enforce this at the repository layer, not the controller layer, so there's no path through the codebase that can accidentally omit it.
• Composite indexes on (organizationId, entityId). Beyond security, this is a performance decision. Scoped indexes mean queries for a single store never scan rows belonging to other stores.
• Soft deletes retain the organizationId. Even when a record is logically deleted, its ownership metadata stays intact. This matters for audit trails and GDPR erasure verification.

Think of organizationId as a load-bearing wall in the data model. Remove it — or forget to filter on it — and the whole structure becomes unsafe.

JWT Roles and the Trust Boundary at the API Layer

Database scoping handles storage-level isolation, but you also need to enforce isolation at the request level — before a query is even constructed. This is where our JWT architecture comes in.

When a Shopify merchant installs Retenza and authenticates via OAuth, we issue a signed JSON Web Token that encodes three critical claims:

• organizationId: The unique identifier for this merchant's workspace.
• role: The permission level of the authenticated user — e.g., owner, agent, or viewer.
• shopDomain: The canonical Shopify domain, used to validate Shopify API calls made on behalf of this tenant.

Every inbound API request is authenticated by extracting and verifying this JWT. The organizationId is then injected into the request context and flows through every service call downstream. Crucially, the organizationId in the token is never overridden by anything in the request body or query parameters. A bad actor cannot claim to belong to a different organization simply by passing a different ID — the signed token is the only source of truth.

The role claim adds a second layer: even within the same organization, an agent cannot access billing data or change store-level settings — those are restricted to the owner role. Role-based access control (RBAC) is enforced via middleware guards that check both the role claim and the resource being requested before any handler logic runs.

Shopify API Calls: Scoped Credentials, Not Shared Ones

One subtle but important isolation concern is how Retenza fetches real-time order data from Shopify. To generate a useful reply to a "where is my order?" email, we need to call Shopify's Admin API and retrieve order details for that store.

This is where credential isolation matters as much as data isolation. Retenza stores each merchant's Shopify access token encrypted at rest, keyed to their organizationId. When we need to fetch order data, we:

• Retrieve the access token for the specific organizationId present in the current request context.
• Construct an API client scoped to that store's domain and token.
• Discard any references to that client after the request completes — no caching of API clients across tenant boundaries.

This means a request authenticated as Store A can only ever result in Shopify API calls against Store A's data. There is no shared Shopify client that could be misdirected.

GDPR Compliance: Why Isolation Is the Technical Foundation

GDPR compliance for a customer support platform isn't just about having a privacy policy. It requires demonstrable technical controls. Data isolation is the bedrock on which several GDPR obligations rest:

Right to Erasure

When a merchant's customer submits a deletion request, Retenza needs to locate and erase all records associated with that customer — emails, order snapshots, conversation history. Because every record is scoped to an organizationId, and customer identifiers are consistently stored within that scope, erasure queries are precise and auditable. We can generate a deletion receipt that proves exactly what was removed.

Data Processing Agreements and Tenant Segregation

Under GDPR, Retenza acts as a data processor on behalf of each merchant (the data controller). Each merchant's data must be logically — and verifiably — segregated from others. Our organizationId scoping model means we can demonstrate, in an audit, that cross-tenant data access is architecturally prevented, not just operationally discouraged.

Breach Containment

In the event of a security incident, isolation limits the blast radius. A compromised credential for one tenant cannot be used to enumerate or exfiltrate another tenant's data, because every query requires a valid, scoped organizationId that is independently authenticated.

What "Good Enough" Isolation Actually Looks Like

It's worth being honest: perfect isolation in a shared-infrastructure model requires ongoing vigilance, not a one-time architectural decision. A few practices we've adopted to maintain isolation quality over time:

• Automated tests for cross-tenant access. Our test suite includes explicit scenarios where a request authenticated as Tenant A attempts to access resources belonging to Tenant B. These tests are expected to return 403 Forbidden, always.
• Query auditing in staging. We log and periodically review queries that lack an organizationId predicate in staging environments. Any unscoped query is flagged for review before it reaches production.
• Dependency injection of tenant context. Rather than relying on developers to manually pass the organizationId, our service layer receives a typed TenantContext object that is constructed once from the verified JWT and passed through the call chain. There's no global mutable state that could leak between requests.

Building Trust Through Architecture

Merchants who connect their Shopify support inbox to Retenza are trusting us with their customers' data — order histories, email threads, names, addresses. That trust is earned through architecture, not promises. Multi-tenant isolation isn't a feature you ship once and forget; it's a discipline that has to be embedded into how the platform is designed, tested, and evolved.

Retenza was built with this discipline from the ground up. Every conversation processed, every AI-generated draft reviewed by a human agent, every Shopify order fetched — all of it happens within a hard tenant boundary, enforced at every layer of the stack. If you're evaluating AI-powered support tools for your Shopify store and data security is a concern (it should be), we're happy to walk through our architecture in detail.