Como chamar APIs do Google com OAuth 2.0 pelo módulo HTTP

Quando um endpoint do Google não está coberto pelo módulo específico de um aplicativo, o módulo HTTP > Make a request pode enviar a solicitação com autenticação OAuth 2.0. Para isso, você precisa configurar um projeto no Google Cloud, criar um cliente OAuth e conceder somente os escopos necessários para a chamada.

Este procedimento exige familiaridade com a documentação da API que será usada. O método HTTP, a URL, os parâmetros, o corpo e os escopos pertencem ao contrato do serviço do Google; não devem ser deduzidos de um exemplo de outra API.

Preparação

Reúna estas informações antes de criar o cenário:

conta autorizada para configurar um projeto no Google Cloud;

API do Google que será chamada;

endpoint e método HTTP documentados;

escopos mínimos necessários;

formato esperado para parâmetros, cabeçalhos e corpo;

URI de redirecionamento indicada na documentação atual do Make;

dados de teste que não afetem recursos reais.

Se a API tiver um módulo próprio no Make, compare as duas opções. O módulo específico pode oferecer mapeamentos e validações que uma solicitação HTTP genérica não fornece.

1. Criar e configurar o projeto no Google Cloud

Crie um projeto no Google Cloud ou selecione um projeto existente aprovado para a integração. Confirme que você está no projeto certo antes de habilitar serviços ou gerar credenciais.

Na biblioteca de APIs, pesquise o serviço correspondente e habilite a API. Se a chamada usar mais de um serviço, verifique cada dependência na documentação oficial do Google.

Configure a tela de consentimento OAuth com:

nome e contato responsáveis;

público autorizado;

usuários de teste, quando exigidos;

domínios autorizados indicados pelo Make;

somente os escopos necessários para a solicitação.

As regras de teste, publicação e verificação são definidas pelo Google e podem mudar. Consulte a documentação atual antes de usar a conexão fora de um ambiente controlado.

2. Criar o cliente OAuth

Crie um cliente OAuth do tipo Web application. No campo de redirecionamento, copie exatamente a URI indicada na documentação oficial desta integração.

Depois de criar o cliente, guarde o Client ID e o Client Secret em um local seguro. Não coloque o segredo em arquivos do projeto, documentação, mensagens, campos comuns do cenário ou logs.

Uma URI de redirecionamento deve coincidir caractere por caractere. Não altere protocolo, domínio, caminho ou barra final e não reutilize uma URI de outro tipo de conexão sem confirmação.

3. Criar a conexão OAuth no Make

Abra um cenário e adicione HTTP > Make a request.

Em Authentication type, selecione OAuth 2.0.

Crie uma conexão nova.

Escolha o fluxo de código de autorização.

Informe as URIs de autorização e de token publicadas na documentação atual do Google e confirmadas pela fonte oficial do Make.

Adicione somente os escopos necessários para o endpoint.

Informe o Client ID e o Client Secret do projeto correto.

Revise as configurações avançadas, incluindo o separador de escopos e os parâmetros de autorização solicitados pela documentação oficial.

Salve, entre com a conta Google pretendida e revise o consentimento.

Não adicione manualmente um token de acesso ao cenário quando a conexão OAuth já gerencia a autorização. Isso cria duas fontes de credencial e dificulta a renovação segura.

4. Configurar a solicitação HTTP

No módulo HTTP, preencha os valores descritos pela API:

URL: endpoint completo do recurso;

Method: operação exigida, como GET, POST, PATCH ou DELETE;

Query string: parâmetros de consulta quando aplicáveis;

Headers: apenas os cabeçalhos adicionais exigidos;

Body type: tipo de conteúdo aceito pelo endpoint;

Body: estrutura válida para a operação.

Para JSON, valide a estrutura antes de mapear dados dinâmicos. Se o Make permitir gerar uma estrutura a partir de uma amostra, revise todos os campos, tipos e valores opcionais depois da geração.

Comece com a menor solicitação capaz de provar a conexão. Uma leitura controlada costuma ser mais segura do que uma escrita. Quando precisar criar ou alterar um recurso, use um ambiente ou objeto de teste e registre como removê-lo.

5. Testar o módulo

Use Run once e inspecione:

URL final e método;

parâmetros enviados;

corpo gerado;

código de resposta;

cabeçalhos relevantes;

corpo da resposta;

recurso criado ou alterado no Google.

Não registre tokens, códigos de autorização ou segredos durante o diagnóstico. Se precisar compartilhar um erro, remova credenciais e dados pessoais do exemplo.

Diagnóstico de conexão

Falha na URI de redirecionamento

Compare a URI cadastrada no cliente OAuth com a URI indicada pelo Make. Verifique também se as credenciais usadas pertencem ao mesmo projeto em que a URI foi configurada.

Cliente inválido

Confirme Client ID, Client Secret, projeto e cliente OAuth. Se a credencial tiver sido revogada ou substituída, crie uma conexão nova, atualize o cenário e faça um teste controlado.

Acesso negado

Revise o público da tela de consentimento, os usuários de teste, a conta selecionada e as políticas da organização. Depois de qualquer mudança, reautorize a conexão.

Permissão insuficiente

Compare os escopos da conexão com os escopos exigidos pelo endpoint. Habilitar uma API não concede automaticamente todas as permissões. Após corrigir os escopos, obtenha um novo consentimento.

API não configurada

Verifique se a API correta está habilitada no mesmo projeto do cliente OAuth. Confirme também se o endpoint pertence ao serviço habilitado.

Diagnóstico da solicitação

Em erro de validação, compare o corpo e os tipos com o esquema da API.

Em recurso não encontrado, revise o ID, o projeto, a conta e a URL.

Em resposta sem conteúdo esperado, confira parâmetros, paginação e filtros.

Em indisponibilidade ou limitação temporária, respeite a resposta da API e aplique uma política de nova tentativa que não duplique escritas.

Em dúvida sobre um campo, consulte o Google APIs Explorer ou a documentação do serviço antes de alterar a chamada.

Checklist final

A API correta está habilitada.

O consentimento usa o público e os escopos corretos.

A URI de redirecionamento foi copiada da fonte atual.

As credenciais estão protegidas.

A conexão usa os endpoints e parâmetros oficiais.

A solicitação segue o contrato da API.

A execução foi validada com dados controlados.

O caminho de erro não repete uma escrita de forma insegura.

Para confirmar os valores de conexão e a interface atuais, consulte a documentação oficial do Make para chamadas a APIs do Google com OAuth 2.0.