Connecting an OAuth2 API to Make.com is not mainly a matter of copying a client ID and secret. The connection works only when Make.com and the external service agree on the authorization endpoint, token exchange, redirect URI, scopes, token response and renewal process.
The reliable approach is to treat OAuth2 as a small integration design problem. First identify the API’s authorization model, then configure the Make.com custom app, authorize a controlled test connection and verify that the resulting token supports the actual business action your scenario needs.
This matters because a connection can appear to work while still having the wrong scope, an incomplete token response or no reliable refresh path. Those gaps usually surface later as failed scheduled runs, unexpected reauthorization requests or scenarios that can read data but cannot update it.
What you need before configuring OAuth2 in Make.com
OAuth2 is an authorization protocol. It allows a user to grant an application limited access to an external service without sharing the user’s password with that application. Make.com uses the authorization flow to obtain an access token, then sends that token with requests made by a module or HTTP-based scenario.
Before opening the Make.com app configuration, collect the integration details from the external service’s developer documentation. Do not assume that two OAuth2 providers use the same parameters or response format.
- Authorization URL, where the user grants consent
- Token URL, where an authorization code is exchanged for tokens
- Client ID and client secret for the registered application
- Required scopes for the actions the scenario will perform
- Supported grant type and any PKCE requirements
- Redirect URI requirements
- Access token lifetime and refresh token behavior
- Token response field names and authentication method
OAuth2 configuration is complete only when the authorization flow and the intended API operation both work. A successful login alone is not proof that the integration is usable.
Create the Make.com custom app
A custom app provides the configuration Make.com uses to authorize and reuse a connection. The exact labels can change as Make.com updates its interface, but the setup normally starts in the organization or team area where custom apps are managed.
- Open the relevant Make.com organization.
- Go to the Apps area and create a new custom app.
- Give the app a clear name that identifies the external service and environment.
- Choose OAuth2 as the authorization method.
- Save the draft so Make.com can expose the callback or redirect information required by the provider.
Use separate app registrations for environments when the external service treats development, staging and production differently. This makes authorization ownership and troubleshooting clearer than sharing one credential set across every scenario.
Configure the OAuth2 authorization flow
Enter the authorization and token endpoints
The authorization URL sends the user to the external service’s consent screen. The token URL receives the authorization code and returns an access token, and sometimes a refresh token. Some providers use the same endpoint for access and refresh operations, while others document separate endpoints.
Copy the URLs from the provider’s current API documentation. A URL that looks plausible can still be wrong because of a tenant identifier, regional host, version path or required audience.
Register the redirect URI exactly
The redirect URI is the address to which the provider sends the browser after the user approves or rejects access. Make.com supplies the value used by its OAuth2 configuration. Copy that value into the external provider’s allowed redirect URI list without changing it.
Protocol, hostname, path, capitalization and trailing slash differences can cause a redirect URI mismatch. Do not replace a generated callback with a guessed Make.com URL. If the provider allows several redirect URIs, keep the list limited to the environments that are actually required.
Protect the client credentials
The client ID identifies the registered application. The client secret authenticates that application and must be treated as confidential. Store it in Make.com’s connection or app configuration rather than placing it in a scenario field, URL, log message or shared documentation.
A client secret does not grant the same access as a user token, but exposing it can still allow unauthorized parties to impersonate the integration at the provider’s authorization endpoint. Rotate it according to the provider’s process if it is exposed or replaced.
Choose scopes based on actions, not convenience
Scopes describe what the connection is allowed to do. A scenario that reads contacts, creates records and uploads files may need different permissions from one that only reads a single resource.
Start with the smallest set of scopes that supports the required business process. Document the reason for each scope in the app configuration or integration notes. If a permission is added later, record which scenario requires it and reauthorize the connection when the provider requires fresh consent.
Convenience-first access
The integration requests every available permission so configuration is faster. This increases the impact of an exposed connection and makes user consent harder to review.
Action-based access
The integration requests only the permissions needed for defined scenario steps, such as reading orders or creating support records.
Some providers also require additional authorization parameters such as audience, access type, prompt or response type. Treat these as provider-specific requirements. The parameter name, location and accepted value must come from the provider’s documentation rather than from a generic OAuth2 example.
Map access tokens and refresh tokens correctly
After consent, Make.com exchanges the authorization code for an access token. The access token is normally sent in an Authorization header, often using the Bearer scheme, although providers may document another method.
Check the actual token response and confirm which fields contain the access token, token type, expiration information and refresh token. Do not assume that a provider uses standard field names without verifying its documentation.
- Access token: the credential used for API requests.
- Token type: the scheme used when sending the access token.
- Expiration: the time after which the access token is no longer valid.
- Refresh token: a longer-lived credential that may be exchanged for a new access token.
If refresh tokens are supported, confirm that the authorization request includes any required offline or persistent-access option. Confirm also whether the provider issues a new refresh token during renewal. A scenario can work during initial testing and still fail later if the refresh behavior has not been configured correctly.
Token renewal is part of workflow reliability. If nobody owns the refresh path, an integration that depends on daily or scheduled execution can become an invisible single point of failure.
Test the connection against the real business operation
Use a small test scenario before connecting the authorization to a larger workflow. The first test should prove more than authentication. It should confirm that the token has the required scope, the API response can be mapped and the next operational step has clear ownership.
Inspect the API response, Make.com execution history and provider error message together. Common failures include an incorrect redirect URI, missing scope, wrong token endpoint, unsupported grant type, incorrect token placement or a token response that has not been mapped as expected.
Design the scenario around ownership and business states
OAuth2 solves access, not process design. Once the API connection works, define what the scenario should do, when it should run and who owns exceptions. For example, a workflow that sends new CRM records to an external service should define what counts as new, how duplicates are detected and what happens when the external API rejects a record.
A useful diagnostic question is: What business state should change when this API call succeeds? If the answer is unclear, the integration may be automating activity without creating a reliable operational outcome.
Use a clear status, timestamp or reference ID to show that the external action occurred. Avoid treating a successful Make.com execution as proof that the business process is complete if the response has not been stored or reconciled.
An API connection is a technical capability. A reliable integration is a controlled business process with an owner, a success condition and a recovery path.
Example: connecting a service to an order workflow
Consider a hypothetical scenario in which an operations team wants Make.com to send approved orders to an external fulfilment API. The OAuth2 connection may authorize successfully, but the workflow still needs decisions around approval status, duplicate order IDs, required scopes and rejected requests.
A sensible sequence would be to trigger only when an order reaches the approved state, send the minimum order data required by the API, store the external reference returned by the API and update the order with a submitted or failed status. A separate exception path can assign rejected orders to an operations owner instead of repeatedly retrying an invalid request.
This separation keeps authorization, data mapping and business ownership visible. It also makes it easier to change the external API connection without redesigning the entire order process.
OAuth2 connection checklist
- The authorization URL and token URL come from the provider’s current documentation.
- The redirect URI matches exactly on both sides.
- The client secret is stored securely and is not exposed in scenario data.
- Scopes match defined actions rather than a broad default.
- The token type and token location are correct.
- Access token expiry and refresh behavior have been tested.
- Read and write operations have been tested separately where relevant.
- Failures have a visible owner and a documented recovery action.
- The scenario records enough information to reconcile successful external actions.
When a custom OAuth2 connection needs more design
A custom app is useful when Make.com does not provide a ready-made connector or when the available connector does not support the required endpoint. More configuration is needed when the service uses unusual token fields, tenant-specific authorization, PKCE, custom headers, special audience values or strict environment separation.
At that point, adding more modules is not automatically the answer. Review the process, data ownership and exception handling first. A connected operating system may require CRM architecture, data mapping or integration design alongside the OAuth2 configuration. ConsultEvo’s CRM consulting service covers CRM structure, lead management, automation and integrations, while the systems and automation services support broader workflow design.
For a relevant example of connected operational systems, see the commerce and operations intelligence platform portfolio page. The useful lesson is not a particular tool choice, but the relationship between connected data, process ownership and decision-ready information.
Make.com can automate the exchange between systems, but the quality of the result depends on the rules around that exchange. Configure OAuth2 carefully, test the real operation and make ownership visible before treating the scenario as production-ready.
Frequently asked questions
What information is required to connect an OAuth2 API to Make.com?
You typically need the authorization URL, token URL, client ID, client secret, required scopes, redirect URI, token response details and any provider-specific parameters such as audience or PKCE requirements.
Why does an OAuth2 redirect URI mismatch occur in Make.com?
It usually occurs when the redirect URI registered with the API provider differs from the value supplied by Make.com. Check the protocol, hostname, path, capitalization and trailing slash exactly.
What is the difference between an access token and a refresh token?
An access token is used to make API requests and usually expires. A refresh token may be exchanged for a new access token so the user does not need to authorize the connection again, subject to the provider's rules.
How should OAuth2 scopes be chosen for a Make.com scenario?
Choose scopes according to the actions the scenario must perform. Request the minimum permissions needed for those actions, and add or review scopes when the workflow changes.
What should be tested after connecting an OAuth2 API to Make.com?
Test authorization, a representative read operation, each required write operation, token expiry or renewal, response mapping and the handling of rejected requests. Also define who owns failed runs.
Make the API connection part of a reliable workflow
If an OAuth2 connection is only one part of a larger automation, ConsultEvo can help clarify the process, data ownership, exception handling and system design around it.
