Multi-Tenant Integration Architecture: How to Offer Integrations Without Leaking Credentials

This maps cleanly to how your customers think about their integrations. Each workspace is self-contained: you can show a customer their own delivery logs, their own connections, and their own rules without exposing anything from other tenants.

It also simplifies credential rotation. When Tenant A rotates their HubSpot key, you update the connection inside Workspace A. Nothing else is affected.

Pattern 2: Shared infrastructure, logical isolation

You don't need separate queues, databases, or compute for each tenant. That would be wildly expensive. The goal is logical isolation on shared infrastructure.

In practice, this means:

• One event bus, but events carry a workspace identifier. The routing layer evaluates rules scoped to that workspace.
• One delivery engine, but retry state and dead letters are tracked per connection, not globally. A failing connection for Tenant A doesn't block Tenant B's queue.
• One credential store, but access is scoped. The delivery engine for Workspace A can only read Workspace A's secrets.

This is the standard approach for B2B SaaS. It keeps infrastructure costs manageable while maintaining the isolation guarantees your customers expect.

What goes wrong without isolation

The failure modes are predictable and painful:

Credential cross-contamination. You store all HubSpot API keys in a flat table, and a bug in your lookup logic returns the wrong key for a tenant. Now you're pushing Tenant A's leads into Tenant B's CRM. This is a data breach, full stop.

Queue head-of-line blocking. You use a single queue for all webhook deliveries. Tenant C's endpoint goes down and events start backing up. The queue depth grows. Now Tenant D's events, which are perfectly deliverable, are stuck behind Tenant C's failed retries. Delivery latency spikes for everyone.

Noisy-neighbor alerts. You set up an alert on dead-letter volume. Tenant E has a misconfigured webhook that generates a thousand dead letters a day. Your alert fires constantly, and you stop paying attention. When Tenant F has a real delivery failure, you miss it in the noise.

Debugging in the dark. A customer reports missing events. Your logs show thousands of delivery attempts across all tenants with no easy way to filter by customer. You spend hours grep-ing through logs instead of minutes clicking into a workspace.

Credential management patterns

Credentials are the highest-risk piece of multi-tenant integrations. A few patterns that help:

Encrypt at rest, scope on read. Store credentials encrypted. When the delivery engine needs a credential, it fetches it by workspace + connection ID. Never allow cross-workspace credential lookups.

OAuth token lifecycle. For destinations that use OAuth (Salesforce, HubSpot, etc.), you need to handle token refresh per tenant. Store the refresh token, exchange it for an access token before delivery, and handle the case where a customer revokes access.

Customer-managed credentials. Let customers provide and rotate their own keys through a UI or API. This reduces your support burden and gives customers control over their own security posture.

Audit logging. Log every credential access—who, when, and for which delivery. If a credential is compromised, you need an audit trail.

How Meshes handles multi-tenancy

Meshes is built around the workspace-per-tenant model. When you onboard a customer, you create a workspace. Inside that workspace:

• Connections hold per-tenant credentials and destination configuration.
• Rules define routing logic scoped to the workspace.
• Event logs show delivery status per event, per destination, per workspace.

Your app sends events tagged with a workspace ID:

The platform evaluates rules for ws_tenant_abc, looks up the correct credentials for each matched connection, and delivers the event—with retries, dead letters, and observability all scoped to that workspace.

No credential leakage. No cross-tenant queue interference. No shared logs to wade through.

When multi-tenancy matters

If your product is used by a single team with a single set of integrations, you don't need multi-tenant isolation. A shared configuration works fine.

Multi-tenancy becomes critical when:

• Your customers bring their own credentials. If each customer connects their own HubSpot or Salesforce instance, you need per-tenant credential storage and isolation.
• You offer integrations as a feature. If your pricing page says "connect to 10+ destinations," you're promising per-customer configurability. That requires per-tenant routing.
• You operate in regulated environments. Healthcare, finance, and enterprise customers often require proof of data isolation. A workspace model with scoped credentials and audit logs makes compliance audits dramatically simpler.
• You need per-customer observability. When Tenant A opens a support ticket about missing events, you need to pull up Tenant A's delivery logs—not search through a shared haystack.

The takeaway

Multi-tenant integrations aren't just "the same integration, but for many customers." They require deliberate architectural choices around credential isolation, delivery isolation, routing scope, and per-tenant observability.

You can build this in-house, but it's a significant surface area to maintain—especially as your customer count and integration catalog grow.

Meshes gives you workspace-per-tenant isolation out of the box: scoped credentials, scoped routing, scoped delivery, and scoped logs. You focus on your product. The integration layer handles the multi-tenancy.

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