Designing Multi-Tenant Integrations for Your SaaS

If your product offers "integrations" as a feature, you're really running a multi-tenant integration platform—even if you don't call it that yet.

That means answering questions like:

• How do we isolate credentials per customer?
• How do we let customers configure their own CRMs / webhooks?
• How do we support sandbox vs production?
• How do we reason about limits (events, connections, rules) per tenant?

This post walks through some practical patterns using the idea of workspaces as the core isolation unit. (For a deeper dive into credential isolation, failure isolation, and the security risks of getting multi-tenancy wrong, see our companion post on multi-tenant integration architecture.)

Workspaces as the integration boundary

A workspace is a container for:

• connections (OAuth + API keys)
• rules (routing & fan-out)
• events + audit history
• usage limits (events, rules, etc.)

Most teams map workspaces to one of three things:

1. Customer – workspace = tenant
2. Customer + Environment – workspace = tenant + env
3. Internal environment – workspace = app + env

Pattern 1: One workspace per customer

Best when:

• You're reselling integrations to customers.
• Each customer can connect their own tools (HubSpot, Salesforce, Mailchimp, etc.).
• You want clean isolation of credentials and rules.

Mapping might look like:

// Your tenant model
type Tenant = {
  id: string; // "cust_123"
  slug: string; // "acme-co"
  workspaceId: string; // "ws_01..."
};

Each customer gets:

• their own workspace
• their own connections
• their own rules

Benefits:

• Simple mental model: "Open ACME's workspace."
• Easy to attribute usage per customer.
• No credential sharing or risk of cross-tenant leaks.

Pattern 2: One workspace per customer per environment

Best when:

• You support sandbox vs production integrations.
• Customers want to test mapping/routing before going live.

Mapping:

• cust_123 + sandbox → ws_cust123_sandbox
• cust_123 + prod → ws_cust123_prod

Pros:

• Clear separation of test vs live traffic.
• You can apply different limits for sandbox (lower) vs prod (higher).
• You can safely experiment in sandbox without touching real data.

Pattern 3: Internal-only workspaces

If customers never configure integrations directly and you just need a hub between your own systems:

• Use a few shared workspaces:
  • internal-dev
  • internal-staging
  • internal-prod
• Put tenant IDs into event resource data, not separate workspaces.

Example event:

{
  "workspace": "ws_internal_prod",
  "event": "invoice.paid",
  "resource": "billing-core",
  "resource_id": "cust_123",
  "payload": {
    "invoiceId": "inv_123",
    "amount": 19900
  }
}

Rules and mapping can branch based on resource and resource_id if needed.

Credential isolation per tenant

Multi-tenant integrations mean credentials per tenant:

• ACME connects their HubSpot.
• Contoso connects a different HubSpot account.
• Startups might use MailChimp instead.

You don't want:

• shared tokens
• shared webhooks
• shared rate limits

Without proper isolation, the failure modes are predictable and painful: credential cross-contamination leaks data between tenants, shared queues create head-of-line blocking, and debugging becomes impossible when logs have no tenant context. (We cover these failure modes in detail in our post on multi-tenant integration architecture.)

With a workspace-based model:

• each workspace has its own connections
• each connection has its own auth (OAuth, API key, etc.)
• rotation & revocation happen per workspace/connection

If you build this on top of Meshes, you get:

• per-workspace connections (no cross-tenant sharing)
• per-workspace limits (events, rules, connections)
• a clean API: your app just needs workspaceId for each tenant

Limits and pricing become clearer

Once you have a workspace-per-tenant mapping, usage becomes:

• events per workspace
• connections per workspace
• rules per workspace

That makes it much easier to:

• align your own pricing (e.g. "5 workspaces, 15 connections")
• build internal guardrails (hard caps vs enterprise soft overages)
• see who is noisy vs who is quiet

The build-vs-buy decision for multi-tenant infrastructure

Building multi-tenant integration infrastructure in-house is absolutely possible. But it's a larger surface area than most teams anticipate: credential storage with encryption and scoped access, per-tenant queue isolation, workspace-level observability, and audit logging for compliance. The initial build might take a month. The ongoing maintenance—credential rotation flows, handling OAuth token lifecycle per tenant, debugging cross-tenant issues—is what accumulates.

Teams building multi-tenant SaaS products are already stretched thin building multi-tenancy into their core product. Adding it to the integration layer too means maintaining two parallel multi-tenant systems.

Putting it together with Meshes

At a high level, your integration flow becomes:

1. On tenant signup, create a workspace for them.
2. When they connect a tool, create a connection in that workspace.
3. When they enable an integration, create rules in that workspace.
4. When your app emits events, include the workspaceId for that tenant.

The delivery engine handles retries and dead letters per connection, routing and fan-out per workspace, and CRM sync without your team maintaining per-destination pipelines.

You keep your core app simple, but give each tenant a robust integration layer with isolation, limits, and observability built-in.

If you're starting fresh, this is the perfect time to design the multi-tenant story instead of bolting it on later.

Building integrations for your customers? Join Meshes and get multi-tenant isolation without building the infrastructure yourself.