What authentication methods does Make (formerly Integromat) support?

Make supports common authentication methods including OAuth 2.0, API Key, Basic Authentication, and can handle custom authentication schemes via its HTTP module, such as token-based authentication in headers or query parameters.

How do I secure my API keys and credentials in Make?

Make encrypts and securely stores your credentials. Best practices include using the principle of least privilege when setting permissions, regularly rotating API keys, and ensuring your Make account itself is secured with strong access controls and multi-factor authentication if available.

Can I use OAuth 2.0 with Make for services like Google or Salesforce?

Yes, Make has extensive support for OAuth 2.0. For many popular services, Make provides pre-built app connectors that guide you through the OAuth authorization flow, allowing you to grant delegated access without sharing your direct credentials.

How do I add a new connection with authentication in Make?

To add a new connection, select the desired app module in a scenario, then click 'Add' next to the connection field. Make will prompt you to enter the necessary credentials or guide you through the OAuth authorization process specific to that application.

What if an app I want to connect to isn't directly supported by Make?

If an app isn't directly supported, you can use Make's 'HTTP' module to send custom API requests. This allows you to manually configure headers, query parameters, and body for authentication, accommodating various API security models.

Are my credentials stored securely by Make?

Yes, Make employs encryption for all stored credentials and adheres to security standards such as SOC 2 Type II, GDPR, and ISO 27001 to protect sensitive information.

How can I verify the authenticity of incoming webhooks to Make?

Many services that send webhooks offer signature verification or shared secret keys. You can configure your Make webhook module to check these signatures or secrets, ensuring that the incoming data is legitimate and has not been tampered with.

Make (formerly Integromat) Authentication Methods (2026)

Authentication overview

Make (formerly Integromat) facilitates integrations between various applications by acting as an intermediary that passes data and executes actions. For Make to interact with external services on a user's behalf, it requires proper authentication. This process verifies the identity of the user or application and grants Make the necessary permissions to access specific resources or perform operations within the connected service.

The platform manages connection credentials securely, encrypting them and storing them separately from scenario definitions. When a scenario runs, Make uses these stored credentials to authenticate with the target service, ensuring that data transfers and operations are authorized. Make's approach to authentication is designed to accommodate the diverse security requirements of thousands of integrated applications, ranging from simple API key mechanisms to complex OAuth 2.0 flows.

Users establish a connection once for each service using their credentials, and Make reuses this connection across multiple scenarios. This centralized connection management simplifies workflow creation and updates, as credential changes only need to be made in one place. Make's comprehensive help documentation provides detailed guides on establishing connections for specific apps and understanding the underlying authentication mechanisms.

Supported authentication methods

Make supports several standard authentication methods to connect with third-party applications. The specific method available depends on the API design of the application being integrated. Users typically configure these methods when creating a new connection within the Make platform.

Method	When to Use	Security Level
OAuth 2.0	When a service supports delegated authorization without sharing user credentials directly with Make. Common for user-facing applications like Google, Salesforce, and social media platforms.	High (token-based, scope-limited, revocable)
API Key	When a service provides a unique key or token for authenticating API requests. Often used for server-to-server communication or applications where a single key grants access to specific resources.	Medium (requires careful handling, often has broad permissions)
Basic Authentication	When a service requires a username and password (or similar pair) sent with each request, typically Base64 encoded. Less common for modern APIs, but still present in some legacy systems.	Medium (credentials sent with each request, relies on HTTPS for transit security)
Webhooks	While not strictly an authentication method for Make to connect to other services, webhooks are a common way for other services to notify Make. Authentication for incoming webhooks often involves shared secrets or signatures to verify the sender.	Varies (depends on implementation, e.g., signature verification for Twilio webhooks)
Custom HTTP Request	For APIs not directly supported by a pre-built Make app, allowing manual configuration of headers, query parameters, and body for authentication (e.g., custom token in header).	Varies (depends on API's specific security model)

OAuth 2.0 is a common authorization framework that allows third-party applications like Make to obtain limited access to a user's resources on an HTTP service, without exposing the user's credentials. Instead, it issues access tokens. For instance, when connecting to a Google service, Make requests authorization, and the user approves this request directly with Google, granting Make an access token to perform actions within defined scopes. This process is detailed in the OAuth 2.0 specification.

API Keys are typically strings of characters that a service provider issues to a user or application to identify and authenticate them when making API requests. These keys are often passed as a query parameter or an HTTP header. For example, a Stripe API key grants access to its payment processing functionalities, as described in the Stripe API keys documentation.

Basic Authentication involves sending a username and password, typically Base64 encoded, in the Authorization header of an HTTP request. While simple, its security relies heavily on the use of HTTPS to encrypt the transmission of these credentials. This method is defined in RFC 7617 for HTTP Basic Authentication.

Getting your credentials

The process for obtaining credentials varies significantly based on the specific external service you intend to connect with Make. Generally, credentials are generated or retrieved from the developer console or settings page of the target application.

For OAuth 2.0 connections: You typically start by registering Make as an application with the service provider. This involves creating an application within the service's developer portal (e.g., Google Cloud Console for Google APIs, Salesforce Setup for Salesforce). During registration, you will obtain a Client ID and Client Secret. You also need to configure redirect URIs, which Make provides during the connection setup process. For example, to connect to Google services, you would follow the steps outlined in the Google OAuth 2.0 documentation to create API credentials.
For API Key connections: API keys are usually generated directly within the account settings or developer dashboard of the service. These keys are often displayed once and should be copied and stored securely immediately. For instance, obtaining a Twilio Account SID and Auth Token involves navigating to your Twilio Console Dashboard.
For Basic Authentication: The credentials are typically the username and password associated with your account on the external service, or sometimes specific API users created for integration purposes. These are retrieved from the service's user management or account settings.
For Webhooks: When setting up a webhook in Make, Make provides a unique URL. This URL is then configured in the external service's settings to send data to Make. For securing webhooks, many services offer options like signing requests with a secret key, which Make can then verify. Refer to the specific service's webhook documentation, such as PayPal's webhook integration guide for details on setting up and securing webhook notifications.

Always consult the official documentation of the specific application you are trying to connect to for the most accurate and up-to-date instructions on obtaining credentials. Make's own help documentation also contains specific guides for popular apps.

Authenticated request example

Since Make operates as a visual workflow builder, direct code examples of authenticated requests are typically abstracted away from the user. Instead, users configure connections within the Make interface, and the platform handles the underlying HTTP requests and authentication headers. However, for custom HTTP modules, you can manually configure authentication details.

Consider a scenario where you are using a custom HTTP module in Make to interact with an API that requires an API key in the Authorization header. Although you configure this visually, the underlying request would resemble the following:

GET /api/v1/data HTTP/1.1
Host: example.com
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

In Make's HTTP module configuration, you would specify:

URL: https://example.com/api/v1/data
Method: GET
Headers: Add a header with Key Authorization and Value Bearer YOUR_API_KEY

For OAuth 2.0, Make's built-in app connectors manage the token exchange process. When you select an app like Google Sheets, Make prompts you to authorize the connection through Google's consent screen. Once authorized, Make securely stores the access and refresh tokens and automatically includes the necessary Authorization: Bearer <access_token> header in subsequent requests to Google APIs.

Security best practices

Securing your integrations within Make is crucial to protect sensitive data and prevent unauthorized access. Adhering to these best practices enhances the overall security posture of your automated workflows:

Limit Permissions (Principle of Least Privilege): When connecting to services using OAuth 2.0, always grant only the minimum necessary scopes or permissions. For API keys, ensure the key's associated role or user account has only the permissions required for the tasks your Make scenario will perform. Avoid using super-admin credentials for integrations. This limits the potential damage if credentials are compromised.
Use Strong, Unique Credentials: For basic authentication or services requiring API keys, use long, complex, and unique credentials. Avoid reusing passwords or keys across different services. Make's platform encrypts stored credentials, but strong initial credentials reduce vulnerability.
Regularly Rotate API Keys and Secrets: Periodically generate new API keys and update them in your Make connections. This practice minimizes the window of opportunity for a compromised key to be exploited. While Make does not automatically rotate keys, it provides the functionality to easily update connections with new credentials.
Secure Webhooks: If using webhooks for incoming data to Make, configure security features provided by the sending service. This often includes secret keys or signature verification. Make's webhook module can be configured to verify signatures, ensuring that incoming data originates from a trusted source. For example, Cloudflare's explanation of webhook security highlights the importance of secret keys.
Monitor Activity and Logs: Regularly review audit logs and activity reports within Make and the connected services. Unusual activity could indicate a security incident. Many services provide logging capabilities that show API calls made with specific credentials.
Restrict Access to Make Accounts: Implement strong access controls for your Make accounts. Use multi-factor authentication (MFA) if available, and ensure that only authorized personnel have access to create, modify, or view connections and scenarios.
Understand Data Handling: Be aware of what data your scenarios are processing and where it is being sent. Ensure that sensitive data is handled in compliance with relevant regulations (e.g., GDPR, HIPAA) and your organization's policies. Make's security documentation outlines its compliance certifications.