Skip to content

PATTERN Cited by 1 source

Per-tenant workspace in third-party SaaS

When to use

You have:

  • A multi-tenant platform with N independent customers (retailers, organizations, projects).
  • A dependency on a third-party SaaS for some non-core capability (marketing automation, customer support, payment processing, observability).
  • A strong tenant-isolation requirement — cross-tenant data leakage is unacceptable.
  • A vendor that supports a workspace primitive (a.k.a. project, account, organization, space — terminology varies) inside its API.

The pattern

Provision a dedicated workspace per tenant inside the third-party SaaS. The vendor's workspace boundary becomes the platform's tenant boundary for that capability.

The platform is responsible for:

  1. Provisioning — when a new tenant onboards, the platform automates workspace creation in the vendor.
  2. Routing — every API call from the platform to the vendor includes the workspace identifier so the vendor enforces the boundary.
  3. Operational machinery the vendor doesn't provide — typically: bulk template deployment, automated IP warming, per-workspace metric aggregation, vendor abstraction.

The vendor is responsible for:

  1. Data isolation — workspace A's customer data can't be read from workspace B.
  2. Configuration isolation — workspace A's templates, identity, branding are scoped to A.
  3. Often: rate-limit isolation — see concepts/per-tenant-rate-limit.
  4. Often: failure isolation — issues in workspace A don't cascade to workspace B.

Canonical instance — Instacart Storefront Pro marketing

Verbatim from the 2026-05-14 source (sources/2026-05-14-instacart-scaling-personalized-marketing-for-multi-tenant-commerce-platforms):

"We provision a dedicated workspace for each retailer within the third-party provider. A workspace is an isolated account with its own customer data, templates, and configuration. This per-retailer workspace model guarantees data isolation and brand integrity across the platform."

"At the final stage, messages are sent through isolated third-party workspaces for each retailer. This model ensures customer data stays separated, templates remain brand-specific, rate limits are managed independently, and each retailer's brand identity is preserved throughout the delivery flow."

"We also isolate failures at the workspace level so issues affecting one retailer do not cascade across the broader system."

Three boundary properties stack: data, configuration, rate-limit, brand identity, and failure-isolation domain all align at the workspace grain. Per-retailer workspaces are the substrate for 350+ retailers on Storefront Pro at the time of writing.

Pipeline shape

   Platform (Instacart)
       │
       ▼
   ┌────────────────────────────────┐
   │ workspace-aware routing layer  │ ◀── e.g. CRM Service
   │ (maps tenant → workspace ID)   │
   └────────────────────────────────┘
       │
       ▼
   Third-party SaaS API
       │
       ├── workspace: tenant A ── (isolated data + templates + budget)
       ├── workspace: tenant B ── (isolated data + templates + budget)
       ├── workspace: tenant C ── (isolated data + templates + budget)
       └── ...

Why this pattern instead of alternatives

Alternative Tenant boundary Tradeoff
Single workspace + tenant tags on every record App-layer tag filter Cheapest. Risky — one missed tag = data leak.
Per-tenant workspace Vendor-enforced workspace Vendor handles the boundary; platform handles operational gaps.
Per-tenant vendor account Vendor billing account Strongest isolation. Operationally expensive (per-account billing setup).

The per-tenant-workspace pattern is the sweet spot when the vendor supports the workspace primitive: vendor-enforced isolation without the per-tenant-account onboarding tax.

What the platform still has to build

  • Workspace provisioning automation. New-tenant onboarding must create the workspace, configure sender/identity, prime templates, allocate IP pools.
  • Per-tenant routing. The CRM Service in the Instacart instance maps each request to the correct retailer workspace.
  • Bulk template deployment. N workspaces means N×M template-update API calls — only viable through automation. See patterns/template-deployment-via-cicd-metadata-file.
  • Automated IP warming — each workspace's sender reputation needs its own ramp. See patterns/automated-ip-warming-with-deliverability-feedback.
  • Cross-workspace metric aggregation. Operational dashboards roll up per-workspace data into one platform view. Instacart uses Datadog (operational) + Snowflake (business reporting) for this.
  • Vendor abstraction — see patterns/vendor-abstraction-service-layer. Workspaces are non-portable, so the platform isolates vendor-specific behavior in a single service to keep the option of provider swap open.

Caveats and tradeoffs

  • Workspace count caps. Most vendors cap workspaces per parent account. Beyond the cap: pay for multiple parent accounts or merge low-volume tenants.
  • Brand vs operational tradeoff. Workspace-per-tenant enables brand isolation, but identity primitives like email from-address may still be platform-controlled (Instacart uses retailerName@example.com rather than per-retailer domains, accepting weaker brand-purity for stronger operational automation).
  • Vendor lock-in. Workspaces are non-portable; migration off the vendor is a per-workspace re-creation effort. Pair with patterns/vendor-abstraction-service-layer to preserve the option.
  • Vendor-shaped scars. If the vendor's workspace model is weak (workspaces share rate limits, identifiers leak between workspaces), the boundary leaks. The platform inherits whatever boundary properties the vendor provides.
  • Cross-workspace operations are awkward. Platform-admin views require N parallel API calls or vendor-side admin permissions.

Composes with

Seen in

Last updated · 542 distilled / 1,571 read