Os cabeçalhos mostram um 200, então o GHL realmente recebeu sua solicitação corretamente; o problema está no que você está enviando.
A primeira coisa que eu faria é abrir a saída do nó HTTP Request no n8n e examinar o corpo real da resposta, não apenas os cabeçalhos. O GHL às vezes retorna 200, mas esconde uma mensagem de erro no corpo, como um campo obrigatório ausente ou contato não encontrado.
Além disso, verifique os nomes dos campos: o GHL é rigoroso quanto à capitalização. Use firstName em vez de first_name, phonePhone em vez de phone, coisas assim. Se uma chave estiver errada, ele simplesmente a ignora silenciosamente e segue em frente, o que é super chato para depurar.
Em seguida, vá até o próprio GHL e verifique se o contato realmente foi criado ou atualizado. Se ele estiver lá, mas os campos estiverem vazios, é um problema de mapeamento. Se ele não estiver lá de jeito nenhum, você pode estar acessando o endpoint errado ou faltando um campo obrigatório, como e-mail ou número de telefone.
Compartilhe o corpo que você está enviando e o corpo real da resposta, e eu posso te dizer exatamente o que está errado.
Sem o payload da solicitação e o corpo real da resposta, não há evidências suficientes para determinar se isso é um problema interno do n8n ou um problema de payload/mapeamento da API.
exatamente, por isso pedi o corpo da resposta e o payload na minha última mensagem. assim que eles compartilharem, saberemos com certeza de qual lado está o problema.
E aí, @wathoo, bem-vindo à comunidade! Eu sou o Jay, um criador verificado da n8n.
Um status 200 com corpo vazio do GHL geralmente significa que a requisição chegou ao servidor, mas os dados não foram processados — isso é um problema de payload, não de conexão. Algumas coisas para verificar enquanto você compartilha o corpo/resposta completo:
1. O corpo da resposta é a chave - No n8n, após a execução da requisição HTTP, clique na saída. Observe o campo body na resposta. O GHL frequentemente retorna {"succeded":true} ou uma mensagem de erro mesmo em respostas 200.
2. Verifique seu cabeçalho de Autorização - O GHL exige Bearer YOUR_ACCESS_TOKEN no cabeçalho. Além disso, confirme que você está usando o token de localização correto (e não o token da agência) para a criação de contatos.
3. A nomenclatura dos campos é rigorosa - A API do GHL para contatos usa camelCase exato: firstName, lastName, email, phone. Qualquer variação faz com que o campo seja ignorado silenciosamente.
4. Certifique-se de estar apontando para o endpoint correto - Para criar/atualizar um contato, deve ser:
POST https://services.leadconnectorhq.com/contacts/ com o payload do contato
Você poderia compartilhar uma captura de tela das configurações do corpo do nó HTTP Request e da saída da resposta completa? Isso ajudará a identificar exatamente onde os dados estão sendo perdidos.
@wathoo
A partir da captura de tela, a solicitação ainda não está realmente autenticada. O nó HTTP Request está configurado como Autenticação: Nenhuma, então, mesmo que você tenha adicionado linhas de cabeçalho para Authorization, Version e Content-Type, os valores parecem estar vazios. Eu corrigiria isso primeiro enviando os cabeçalhos GHL necessários com valores reais, especialmente o token Bearer, por exemplo, Authorization: Bearer <access_token>, a versão correta da API e Content-Type: application/json. Depois disso, teste primeiro com um corpo mínimo, como locationId, firstName, email e phone, e então adicione os campos restantes de volta assim que o contato for criado com sucesso.
