makeintegromatmulti-tenantoauthagency

Make (Integromat) Multi-Tenant Setup: One Scenario, All Your Clients

Make has the same static connection problem as n8n. Here's how to build one Make scenario that handles all your clients using dynamic OAuth token routing.

CredBridge Team
·March 14, 2025·9 min read

Make (Integromat) Multi-Tenant Setup: One Scenario, All Your Clients

If you run an automation agency using Make (formerly Integromat), you have already discovered the problem that this article is about. You build a scenario that connects to a client's Google Drive, Microsoft Teams, or Slack workspace. It works perfectly. Then a second client wants the same automation. You clone the scenario, swap out the connection, and run it. Everything works.

Then you have a tenth client. And a twentieth. You now have twenty copies of what is fundamentally the same scenario, each wired to a different connection, each diverging slightly from the others over time. When you need to change the logic - because an API changed, because a client wants a new feature, because you found a bug - you have to make that change twenty times.

This is the Make multi-tenant problem, and it is endemic to the way Make's connection model works. This guide explains why it happens, how agencies currently work around it (and why those workarounds fail at scale), and how a different architectural approach - dynamic token retrieval at runtime - solves the problem definitively.

Understanding Make's Connection Model

How Connections Work in Make

In Make, a "connection" is a stored OAuth token or API key tied to a specific third-party account. When you add a Google Sheets module to a scenario, you are prompted to select or create a connection. That connection is an authorization grant from a specific Google account, stored in Make's credential vault.

Once a connection is attached to a module, it is baked in. The scenario references that specific connection. If you clone the scenario and want it to operate under a different Google account, you must open the clone, navigate to every module that uses a Google connection, and manually swap it to a different connection.

This is by design - Make is primarily designed for connecting a user's own accounts. The connection model works perfectly for that use case. It was not designed for agencies running the same automation under dozens of different client accounts simultaneously.

The Core Limitation for Multi-Tenant Scenarios

The fundamental constraint is this: Make connections are static references, not dynamic values. At scenario design time, you select which account the scenario will use. There is no native way to say "use whichever client's connection is appropriate for this execution."

This means that for each client whose credentials differ, you need either:

  1. A separate scenario (one copy per client), or
  2. A workaround that avoids Make's native connection system entirely.

Most agencies default to option one. This has predictable consequences.

Use Case Examples: Make Agencies Running Scenarios for Multiple Clients

To understand why the multi-tenant problem matters in practice, consider these common agency scenarios:

Case 1: The Email-to-CRM Sync Agency

An agency builds a scenario that watches a client's Gmail inbox, extracts structured data from incoming emails, and creates records in HubSpot. The scenario itself is general - it works for any law firm, real estate agent, or recruiter who wants emails converted to CRM records.

At client one, the agency connects the client's Gmail account and HubSpot instance. At client ten, there are ten separate "Email to CRM" scenarios, one for each Gmail + HubSpot credential pair. When HubSpot updates its API (which it does regularly), the agency must update the HTTP module in all ten scenarios.

Case 2: The Slack Notification Workflow

An agency builds a scenario triggered by a webhook that formats incoming data and posts a notification to a client's Slack workspace. A classic use case: e-commerce order alerts, server monitoring notifications, or lead notifications from a landing page.

The scenario logic is identical for every client. Only the Slack connection changes. At twenty clients, there are twenty "Slack Notifier" scenarios. Updating the message format (perhaps the client wants a new field added) requires editing twenty scenarios.

Case 3: The Microsoft Teams Meeting Summarizer

An agency uses Make to connect Microsoft Graph API, pull recent meeting transcripts, summarize them with an AI module, and post summaries to a Teams channel. This is a high-value automation that multiple enterprise clients want.

The Microsoft OAuth connection is client-specific (each client has their own Azure tenant). Every client needs their own connection and therefore their own copy of the scenario.

Current Workarounds People Use in Make (And Why They Break)

Workaround 1: Duplicate Scenarios

The most common approach. Clone the scenario per client, re-wire all connections, rename the clone with the client name.

Why it breaks at scale:

  • N clients means N scenario copies. Maintenance overhead grows linearly with client count.
  • Version drift is constant - you cannot guarantee all copies are on the same version.
  • Debugging requires knowing which copy belongs to which client.
  • Make's scenario list becomes unmanageable. Searching through "Slack Notifier - ClientA," "Slack Notifier - ClientB," "Slack Notifier - ClientC" ... is error-prone.

Workaround 2: Shared Accounts

Some agencies ask clients to add a shared Google or Microsoft account (owned by the agency) to their workspace with appropriate permissions, then use that single agency-owned connection across all client scenarios.

Why it breaks:

  • Clients are legitimately resistant to adding an external account to their workspace with broad permissions.
  • It is a security and compliance risk - the agency's shared account could have access to data from multiple client workspaces simultaneously.
  • If the shared account's token expires or the account is locked, every client is affected simultaneously.
  • You lose audit trails - actions in client systems appear to come from the agency account, not from a properly scoped service account.

Workaround 3: API Key Rotation via Data Stores

Some advanced Make users store API keys or tokens in Make's built-in Data Stores and retrieve them via a lookup at the start of each scenario. The scenario first queries the data store with the client identifier, retrieves the relevant API key, and uses it in subsequent HTTP modules.

Why it partially works but is still limited:

  • This works for simple API key authentication but not for OAuth tokens, which require a proper token refresh flow (access token + refresh token, with the access token expiring every hour for Google).
  • Make's Data Stores are not an OAuth vault - they do not handle token refresh. If an OAuth access token expires, the scenario fails and there is no mechanism to automatically fetch a new one.
  • Storing raw tokens in Data Stores provides no encryption-at-rest guarantees beyond what Make's general data storage provides.

Workaround 4: HTTP Module with External Token API

This is the most architecturally sound workaround available within Make's current feature set: skip Make's native OAuth connections entirely for multi-tenant use cases, and instead use Make's HTTP module to call an external API that returns the appropriate OAuth token for each client.

This is exactly the pattern that CredBridge is built around - and it works not just as a workaround, but as a proper scalable architecture.

How CredBridge Solves Multi-Tenant OAuth for Make

CredBridge is an OAuth token management API designed specifically for automation agencies. It stores each client's OAuth tokens (for Google, Microsoft, and Slack) in an encrypted vault and exposes a simple REST API that returns the correct, auto-refreshed token for any given client at runtime.

The Architecture

Instead of:

  • Client A → Scenario Copy A with Connection A
  • Client B → Scenario Copy B with Connection B
  • Client C → Scenario Copy C with Connection C

You have:

  • All clients → One Canonical Scenario → CredBridge API → Correct token per client

The scenario receives a client_id at runtime (from a webhook payload, a scheduled parameter, or a lookup in your client database). It calls CredBridge with that client_id. CredBridge returns a valid OAuth access token. The scenario uses that token in the Authorization header of subsequent HTTP module calls.

Why Token Refresh Is the Differentiator

The critical advantage of CredBridge over a simple data store lookup is that CredBridge handles OAuth token refresh automatically.

Google OAuth access tokens expire after one hour. Microsoft access tokens expire after one hour. If you store an access token in a data store and retrieve it six hours after it was issued, it is expired and the API call fails.

CredBridge checks the token's expiry on every retrieval request. If the token is about to expire or has already expired, CredBridge uses the stored refresh token to fetch a new access token from the authorization server before returning it to your scenario. This happens transparently - your scenario always receives a valid, current access token.

If the refresh itself fails (because the client revoked access, or the refresh token expired after an extended period of non-use), CredBridge sends an email alert to the agency so you know to re-authorize that client's connection.

Step-by-Step Setup: Make with CredBridge

Step 1: Sign Up and Add Tenants

Create a CredBridge account and navigate to the dashboard. Click "Add Tenant" for each client. Each tenant is assigned a unique client_id. You will use this ID in your Make scenarios to identify which client's tokens to retrieve.

Step 2: Authorize Each Client's OAuth Accounts

For each tenant in the CredBridge dashboard, generate the OAuth authorization link for the relevant services (Google, Microsoft, or Slack). Send this link to your client. When they click it and authorize, their OAuth tokens are stored in CredBridge's encrypted vault.

You do not need to be logged in as the client, and the client does not need to install anything. They simply click a link, log in to their Google (or Microsoft, or Slack) account, click "Allow," and they are done. Their tokens are now in your vault.

Step 3: Build Your Canonical Make Scenario

Design your scenario as if it will serve all clients - because it will. Use variables wherever client-specific values appear. The first module in the scenario should be a token retrieval call to CredBridge.

Module 1: HTTP - Get Token from CredBridge

  • Method: GET
  • URL: https://api.credbridge.io/token
  • Query string parameters:
    • client_id: {{1.client_id}} (from your trigger data)
  • Headers:
    • Authorization: Bearer YOUR_CREDBRIDGE_API_KEY

This module returns a JSON response like:

{
  "access_token": "ya29.a0AfH...",
  "token_type": "Bearer",
  "expires_in": 3599,
  "scope": "https://www.googleapis.com/auth/drive"
}

Module 2+: HTTP Modules with the Token

In all subsequent HTTP modules that call Google, Microsoft, or Slack APIs, set the Authorization header dynamically:

  • Header name: Authorization
  • Header value: Bearer {{2.access_token}} (where 2 is the output of the CredBridge module)

For example, to list files in a client's Google Drive:

  • Method: GET
  • URL: https://www.googleapis.com/drive/v3/files
  • Headers:
    • Authorization: Bearer {{2.access_token}}

Step 4: Handle the Client Identification

Your scenario needs to know which client it is running for. This comes from the trigger. Common patterns:

  • Webhook trigger: Include client_id in the webhook payload. Send {"client_id": "client_abc", "data": {...}} from whatever system fires the webhook.
  • Scheduled trigger with iterator: Store your client list in a Google Sheet or Supabase table. At the start of the scenario, fetch all active clients and iterate through them, running the core logic for each with the appropriate client_id.
  • Router-based dispatch: A single entry-point scenario routes incoming events to sub-scenarios based on identifying information in the payload (email domain, account ID, etc.).

Step 5: Test with One Client, Then Roll Out

Test the scenario end-to-end with a single test client whose credentials you control. Verify that the CredBridge call returns a valid token and that subsequent API calls succeed. Then add additional clients to CredBridge - they are immediately served by the same scenario without any scenario changes.

Comparison: Make vs n8n for Multi-Tenant Scenarios

Understanding how Make and n8n compare on the multi-tenancy dimension helps you advise clients and make architectural decisions.

Connection Model

Both Make and n8n use static connection selection at design time. Neither platform natively supports dynamic credential selection based on runtime parameters. The multi-tenant problem is identical in both tools. The CredBridge solution applies equally to both.

HTTP Module Flexibility

Both Make and n8n have HTTP modules capable of making arbitrary API calls with custom headers. This is the escape hatch that makes dynamic token retrieval possible in both platforms.

Make's HTTP module is slightly more polished for non-developers - the UI for configuring headers and body is more visual. n8n's HTTP Request node is more flexible for complex scenarios with dynamic URL construction and body templating.

Scenario/Workflow Complexity

Make's scenario builder is generally considered more intuitive for non-technical users. Its visual router concept (paths branching from a single point) maps naturally to business logic. n8n's node-based model is more flexible but has a steeper learning curve.

For multi-tenant use cases, n8n's expression language (JavaScript-adjacent) is somewhat more powerful for building dynamic configurations. Make's use of the {{module.field}} syntax is simpler but less expressive for complex transformations.

Community and Ecosystem

n8n has a larger open-source community and a broader library of community-built nodes. Make has more pre-built integrations (modules) in its official library - over 1,500 apps as of 2025.

For agencies: if your clients use mainstream tools (Google Workspace, Microsoft 365, Slack, HubSpot, Salesforce), Make's library covers you well. If you need niche integrations or custom nodes, n8n's extensibility is the advantage.

Pricing for Agencies

Make's agency pricing is operation-based. High-volume workflows (many executions per month across many clients) can become expensive. n8n self-hosted has no per-execution cost, making it significantly more cost-efficient at scale.

If you are building high-frequency automations (hourly syncs, real-time event processing) for many clients, n8n self-hosted is almost always more economical. For lower-frequency, event-driven workflows for a moderate number of clients, Make's pricing is often reasonable.

The Verdict

For new agencies: n8n offers more long-term scalability and cost-efficiency. For agencies already built on Make: the CredBridge approach removes the primary multi-tenancy obstacle, making Make viable at agency scale.

CredBridge works identically with both tools. Whether your scenario is in Make or your workflow is in n8n, the pattern is the same: one HTTP call at runtime, one token returned, one canonical automation template for all clients.

The Business Impact of Getting Multi-Tenancy Right

The difference between a duplicate-scenario architecture and a single-scenario-with-dynamic-credentials architecture is not just technical cleanliness. It is business leverage.

Maintenance time: With 20 clients and 5 scenario types, a duplicate architecture means 100 scenarios to maintain. A CredBridge-based architecture means 5 scenario templates. When you need to make a change, you spend minutes instead of hours.

Onboarding speed: Adding a new client to a duplicate architecture requires cloning and re-wiring 5+ scenarios. Adding a client to a CredBridge-based architecture means adding a tenant in the dashboard and sending an OAuth link. Five minutes, not fifty.

Error visibility: In a duplicate architecture, an error in one client's scenario is isolated - you see it only if you check that specific scenario. In a CredBridge architecture, all clients run through the same scenario template, so errors surface through your existing error monitoring system, consistently.

Scalability ceiling: Duplicate architectures hit a practical ceiling around 20-30 clients, where the maintenance overhead consumes all available time. CredBridge-based architectures scale to 50+ clients with no increase in maintenance overhead.

Solve the Make Multi-Tenant Problem Today

CredBridge removes the fundamental constraint that forces Make agencies to duplicate scenarios. With CredBridge:

  • One scenario serves all your clients
  • OAuth tokens are automatically refreshed - no manual token management
  • New clients are onboarded in minutes, not hours
  • Token expiry and revocation alerts keep you ahead of problems
  • Both Make and n8n are fully supported

Plans:

  • Solo - $19/month - Up to 10 client tenants. Perfect for growing agencies.
  • Agency - $49/month - Up to 50 client tenants. Built for established multi-client operations.

Start your free trial with CredBridge

Stop duplicating n8n workflows

One workflow for all clients. OAuth tokens managed automatically. From $19/mo.

Start free - first month on us →