How to Use Make.com with Google APIs: OAuth 2.0 Setup and Request Design

Decide what the Google API request must accomplish

Start with the business operation, not the module. Write down the event that starts the scenario, the Google resource that should change or be read, the expected result, and what should happen if the request fails. This prevents a technically valid API call from becoming an unclear or unowned automation.

For example, a workflow might receive a completed project record and create a Google Calendar event, retrieve a document from Drive, or append approved values to a Sheet. Each use case needs a different endpoint, method, scope, payload, and error response.

Before opening Make.com, identify:

• The Google service and API version you need
• The resource and operation, such as list, retrieve, create, update, or delete
• The exact endpoint and HTTP method
• The fields that must be mapped from Make.com
• The result that should be stored, routed, or reported

Prepare Google Cloud and OAuth 2.0

Google APIs generally require an OAuth 2.0 connection that grants Make.com permission to act on behalf of a Google user. In Google Cloud, use a project that is managed by the appropriate owner and enable the specific API required by the request. Enabling one Google API does not automatically enable every other Google service.

Create the OAuth client

1. Open the relevant Google Cloud project and go to APIs & Services.

2. Enable the Google API used by the scenario.

3. Configure the consent screen and provide the application details required by the project.

4. Open Credentials and create an OAuth client ID.

5. Choose the application type expected by the Make.com connection. For the HTTP OAuth 2.0 module, this is typically a web application flow.

6. Copy the redirect URI displayed by the Make.com connection dialog and add it to Google Cloud exactly as shown.

7. Copy the resulting client ID and client secret into a secure location for configuration.

The redirect URI is a precise callback address. Extra characters, a different protocol, or a URI copied from another connection can prevent authorization even when the client ID and secret are correct.

Choose scopes deliberately

Scopes are permission statements attached to the connection. Use the narrowest scope that supports the required operation. A read-only workflow should not request write access, and a workflow limited to one Google service should not request broad access across unrelated services.

Find the exact scope strings in the documentation for the Google API and operation. If multiple scopes are required, enter them in the format expected by Make.com. After changing scopes, reconnect or reauthorize the connection so Google issues consent for the updated permissions.

Also consider who owns the connection. A personal connection may stop working when a user leaves the business or loses access to a shared resource. For operational workflows, document the connection owner, the scenarios that use it, and the Google resources it can access.

Configure the Make.com OAuth 2.0 connection

In your Make.com scenario, add the HTTP app and select Make an OAuth 2.0 request. Create a connection and enter the values associated with the Google Cloud OAuth client.

Field names and connection options can change as Make.com updates its interface, so use the values shown in the current module and the Google API documentation together. Do not copy an authorization endpoint, scope, or token setting from an unrelated integration without checking that it matches the API and flow.

Build the Google API request

Once the connection is authorized, configure the request itself. The OAuth module should handle the authorization token, but you still need to provide a correct endpoint, method, parameters, headers, and body.

Set the method and URL

Use the method specified by the Google API reference:

• GET to retrieve or list resources
• POST to create a resource or start an action
• PATCH to update selected fields
• PUT when the API requires a complete replacement
• DELETE to remove a resource where permitted

Enter the complete endpoint URL, including the correct API version and any required path values. A URL can be syntactically valid while still pointing to the wrong resource type or version.

Add query parameters and headers

Use separate fields for query parameters rather than manually concatenating values into the URL where the Make.com interface allows it. This keeps filters, pagination settings, field selections, and resource identifiers visible to the next person maintaining the scenario.

Common headers include Content-Type: application/json for JSON request bodies and an appropriate Accept header when the endpoint supports it. Do not manually add an Authorization header if the OAuth module supplies it. Duplicating or overriding authentication headers can create confusing failures.

Map the request body

For create and update operations, build the body to match the Google API schema exactly. Use valid JSON, preserve the required nesting, and map values only after confirming their types. A date string, numeric identifier, boolean, and array are not interchangeable simply because they can all be inserted into a text field.

Test the request with fixed sample values first. Then replace those values with mapped data from earlier modules one field at a time. This separates API configuration problems from mapping problems.

Test the request and interpret failures

Use Run once with a controlled input. Inspect the module output rather than checking only whether the scenario completed. Review the status code, response body, response headers, and any identifiers returned by Google.

A useful test sequence is:

1. Confirm the connection can authorize.
2. Send a simple read request against a resource the account can access.
3. Test the create or update request with a safe sample record.
4. Check the returned identifier and verify the result in Google.
5. Run the scenario with mapped production-shaped data.

Separate authentication failures from request failures:

• 401 Unauthorized: Check whether the connection is expired, the client credentials are wrong, or the token is being replaced or overridden.
• 403 Forbidden: Check the requested scope, the user’s access to the resource, API enablement, and any project or organization policy.
• 400 Bad Request: Inspect the method, query parameters, JSON syntax, required fields, and data types.
• 404 Not Found: Check the API version, endpoint path, resource identifier, and whether the resource exists in the account being used.
• 429 or quota-related responses: Review request volume, pagination, retries, and the limits applied to the Google project.

Turn a working API call into a reliable workflow

A successful test is not the same as a production-ready scenario. Decide who owns the connection, which records may be changed, how duplicate requests are prevented, and what happens when Google is temporarily unavailable.

For example, suppose an approved customer request in a CRM should create a Google Calendar event. The scenario should define when the request is considered approved, which user or calendar owns the event, what field becomes the event title, and where the Google event ID is stored. If the scenario runs twice, it should be able to recognize the existing event rather than creating a duplicate.

That ownership and state design is often more important than the HTTP module itself. ConsultEvo’s systems, CRM, automation and AI implementation services take the same process-first view when integrations need to fit into a wider operating model.

Use API integrations as part of a broader operating system

Make.com is useful for coordinating events and data between systems, but adding an API call does not automatically create a good process. The workflow should have a clear trigger, a meaningful business state, an accountable owner, and a visible result.

When a Google API integration feeds reporting, sales operations, finance, or delivery work, review the surrounding data model as well as the request. Connected systems need consistent identifiers, defined handoffs, and reporting that supports a decision. A broader example of this type of connected operational design is described in the commerce and operations intelligence platform portfolio example.

Use AI only when it has a defined job, such as classifying an incoming request before a deterministic Google API action. Keep the permissioned API call, validation rules, and ownership explicit. AI can assist with interpretation, but it should not obscure which records are changed or who is responsible for the outcome.