Data Isolation

Synapse is a multi-tenant platform. Every workspace's data is completely isolated from other workspaces. This isolation is enforced at multiple levels -- both in application logic and at the database itself -- so no single point of failure can expose one workspace's data to another.

How It Works

Synapse uses a shared-infrastructure model where every workspace's data lives in the same database but is separated by workspace identity. Two independent isolation layers ensure data never crosses workspace boundaries:

Workspace A Workspace B

┌─────────────────────────┐ ┌─────────────────────────┐

│ Contacts │ │ Contacts │

│ Events │ │ Events │

│ Flows │ │ Flows │

│ Templates │ │ Templates │

│ ... │ │ ... │

└─────────────────────────┘ └─────────────────────────┘

│ │

└──────────┬───────────────────────┘

│

┌───────┴───────┐

│ Database │

│ (isolation │

│ enforced) │

└───────────────┘

Layer 1: Application-level scoping. Every API request is automatically scoped to your workspace. The workspace identity is extracted from your authentication credentials (API key or JWT) and applied to every database query. There is no API parameter that lets you override or specify a different workspace.

Layer 2: Database-level enforcement. The database itself enforces workspace boundaries independently of the application. Even if a bug in the application layer failed to filter by workspace, the database would still block cross-workspace data access. This is not application logic -- it is a database-level security policy.

What This Means for Your Integration

API Keys

API keys are bound to a single workspace at creation time. A key created in Workspace A cannot access Workspace B's data, even if the X-WORKSPACE-ID header is modified.

X-WORKSPACE-ID: workspace_b_id

X-API-KEY: key_created_in_workspace_a

json

HTTP 403 Forbidden

{

"detail": "API key does not belong to the specified workspace",

"code": "workspace_mismatch"

}

JWT Authentication

If your user belongs to multiple workspaces, specify which workspace to use via the X-WORKSPACE-ID header. The server verifies the user has an active membership in the requested workspace before processing any request.

Authorization: Bearer <jwt_token>

X-WORKSPACE-ID: ws_k7x9m2p4

If the user is not a member of the specified workspace:

json

HTTP 403 Forbidden

{

"detail": "User is not a member of this workspace",

"code": "forbidden"

}

Workspace-Scoped Identifiers

Identifiers like contact external IDs and template slugs are unique within your workspace, not globally. Two different workspaces can have a contact with the same external_id without conflict. This means you can use your own internal IDs as external IDs without worrying about collisions with other Synapse customers.

Event and Message Processing

Asynchronous processing (event evaluation, email sending) is also workspace-scoped. Events from one workspace never trigger flows in another workspace. Each processing job carries the workspace context from ingestion through delivery.

Defense-in-Depth Summary

Layer	What it does	Failure mode
Application scoping	Every query includes workspace filter	If bypassed, database layer still blocks access
Database enforcement	Database rejects any row that does not match the current workspace	Cannot be bypassed by application code
API key binding	Key is permanently tied to one workspace	Mismatched workspace header returns 403
JWT membership check	Server verifies workspace membership on every request	Non-member receives 403

Note

These layers operate independently. A failure in any single layer does not compromise isolation -- the remaining layers continue to enforce workspace boundaries.