Dynamic connections in Make.com

Dynamic connections in make.com let you build flexible integrations that can switch accounts, scopes, and endpoints at runtime, without hard‑coding a single connection into every module. This how‑to guide explains what dynamic connections are, how they work, and how to configure them step by step.

By understanding dynamic connections, you can design reusable, secure, and scalable scenarios that adapt to different accounts and environments on make.com, such as development, staging, and production.

What are dynamic connections in Make.com?

A dynamic connection in make.com is a special type of connection that is not tied to one specific account when you design your scenario. Instead, it is resolved at runtime, based on data coming from previous modules or user input.

In practice, this means a single scenario can:

• Call the same API for different users or tenants.
• Change OAuth2 scopes dynamically.
• Target different API endpoints or environments.
• Reuse one scenario across multiple accounts.

Dynamic connections are particularly useful for partners, SaaS builders, and teams who want to centralize logic in make.com while still keeping each customer’s authentication and configuration separate.

Key concepts for Make.com dynamic connections

Before configuring a dynamic connection, it helps to understand three core elements that make.com uses to handle them.

1. Base connection

The base connection is a standard connection that you create like any other in make.com. It typically uses OAuth2 or an API key to authenticate against a service. The base connection:

• Stores the core authentication method and credentials.
• Defines default scopes and endpoints.
• Is referenced by the dynamic connection at runtime.

You usually create at least one base connection per service or environment.

2. Dynamic fields

Dynamic fields are inputs in your modules that determine how the dynamic connection behaves. In many apps on make.com, these fields can include:

• Account or tenant ID.
• Custom OAuth2 scopes.
• Override API URL or base URL.
• Region or data center selector.

Because these fields are mappable, you can feed them from previous modules, such as records from a database or values from a webhook.

3. Runtime resolution

At execution time, make.com resolves the dynamic connection using the provided dynamic fields. The platform:

1. Reads the values you mapped into dynamic fields.
2. Chooses the correct base connection.
3. Applies any overrides for scopes or endpoints.
4. Executes the API call with the resulting connection profile.

This runtime resolution is what lets one scenario serve many users or environments.

How to create a dynamic connection in Make.com

The following high‑level workflow describes how to set up dynamic connections in make.com. Details can differ per app, but the pattern is similar.

Step 1: Create or select the base connection

1. Open your scenario in make.com.
2. Click the module that will talk to your external service.
3. In the Connection field, create a new connection or select an existing one.
4. Authorize the app if you are prompted, following the normal OAuth2 or API key flow.

This base connection often represents your own developer or service account that is allowed to act on behalf of other users or environments.

Step 2: Enable dynamic connection behavior

Many official and custom apps in make.com expose a specific toggle or option that enables dynamic behavior. While the exact label varies, it usually appears near the connection or authorization section of the module.

1. With your module open, locate advanced or connection‑related settings.
2. Turn on the option that allows account, scope, or endpoint to be provided dynamically.
3. Confirm that new input fields appear for the values that can be overridden at runtime.

Once enabled, the module will rely on these fields, together with the base connection, when the scenario runs.

Step 3: Map dynamic fields from previous modules

To make the connection fully dynamic, use data from earlier modules or triggers.

1. Add a trigger such as a webhook, form submission, or database query.
2. Ensure the trigger outputs identifiers or configuration values, for example:

• User or organization ID.
• Custom OAuth2 scope list.
• Region code or environment (dev, test, prod).
• API base URL.

3. Open the module that uses the dynamic connection.
4. Click the dynamic field (for example, Account ID or Base URL).
5. Map the relevant value from the previous module’s output.

Mapping these values is what lets make.com compute the final connection at execution time.

Step 4: Test the dynamic connection

Before turning the scenario on, always test the behavior of your dynamic connection in make.com.

1. Use sample data in your trigger, such as a test payload or a record representing one user.
2. Run the scenario once from the editor.
3. Open the module that uses the dynamic connection and inspect the execution details.
4. Confirm that the correct account, scopes, and endpoints were used.

If something fails, review the mapped fields and verify that the base connection has the required permissions.

Managing OAuth2 with dynamic connections in Make.com

Many dynamic connection use cases revolve around OAuth2. In make.com, OAuth2 apps can expose parameters that influence how access tokens are issued and used.

Dynamic OAuth2 scopes

Some integrations allow scopes to be set dynamically. This lets you request the minimum required permissions for each call or user.

• Store the scopes per user or per tenant in your own system.
• Pass those scopes into a dynamic field in the module.
• Allow make.com to request or refresh tokens using those scopes.

Always follow the provider’s security guidelines when changing scopes dynamically.

Dynamic endpoints and environments

Dynamic connections in make.com are ideal when an API has multiple base URLs or regions.

• Use one base connection for authentication.
• Store environment or region per customer (for example, eu.api.example.com or us.api.example.com).
• Map the correct base URL into the dynamic endpoint field.

This approach lets your single scenario route traffic to the correct environment without duplicating logic.

Best practices for Make.com dynamic connections

To keep your scenarios maintainable and secure, apply the following practices when designing dynamic connections in make.com.

Organize base connections clearly

• Name base connections by environment and purpose, such as CRM OAuth2 – Production or Billing API – Partner App.
• Document which scenarios rely on each base connection.
• Use folders and naming conventions in make.com to group related scenarios.

Validate incoming configuration data

Because dynamic fields can come from external payloads, always validate the data before using it.

• Add filters to check that required IDs or URLs are present.
• Use routers to handle invalid or missing configuration gracefully.
• Log unexpected values into a data store or another tracking tool.

Monitor and audit your scenarios

Dynamic connections introduce flexibility, so monitoring is critical.

• Regularly review scenario history in make.com for failed runs.
• Set up error handlers to capture and alert on connection‑related errors.
• Periodically verify that scopes and endpoints still follow your security policies.

Additional Make.com resources

For the original reference documentation on dynamic connections in make.com, see the official help article: Dynamic connections documentation.

If you need strategic help designing large‑scale architectures, integrating multiple OAuth2 providers, or optimizing complex scenarios in make.com, you can consult specialist teams such as Consultevo for implementation support and training.

By combining dynamic connections, thoughtful base connection design, and robust validation, you can turn make.com into a powerful integration hub that safely adapts to any account, region, or environment you need to support.