Guia Técnico: Integrando Agilux Engage Squad ao RD Station via Webhooks

A Era da Qualificação em Tempo Real

Existe algo que mata conversão mais rápido do que atraso. Sério. Você já viu aqueles estudos mostrando que se você esperar mais de 5 minutos para responder um lead, as chances de qualificá-lo caem tipo 80%? E mesmo assim, 90% das empresas demoram mais de 2 horas para dar o primeiro retorno. (Eu honestamente não entendo como essas empresas ainda existem, mas enfim.)

É aqui que entra a integração Agilux Engage Squad e RD Station para qualificação de leads. No fundo, a mágica toda é sobre eliminar latência. Você monta uma arquitetura que reage a eventos em tempo real — conversão aconteceu, bam, o dado voa para um agente de IA que já começa a conversar com o lead. Sem polling a cada 10 minutos. Sem scripts que rodam de madrugada e esquecem o cara que preencheu o formulário às 23h47.

Esse artigo é para você que precisa implementar isso de verdade. Engenheiro de automação que vai ter que configurar o endpoint. Ops de marketing que vai mapear os campos. CTO de agência que precisa entender se isso escala ou vai explodir no primeiro pico de tráfego.

Arquitetura Event-Driven: RD Station Marketing para Agilux

O Fluxo de Dados na Prática

Funciona assim: alguém preenche um formulário no RD Station — digamos, um “Solicitar Demo” de uma empresa de SaaS de contabilidade em Curitiba. O RD dispara um HTTP POST instantâneo para o Agilux Engage Squad. O payload JSON vai carregado com email, nome, campos personalizados (tipo orçamento ou CNPJ). O Agilux recebe, processa, e o agente de IA já manda uma mensagem no WhatsApp ou email personalizado em menos de 30 segundos.

Não tem intermediário. Não tem fila de espera. O lead ainda está quente, literalmente com a página aberta no navegador.

Por Que Webhooks Vencem API Polling

Look, eu entendo a tentação de fazer um script que roda a cada X minutos consultando a API do RD para ver se tem lead novo. É mais simples de configurar inicialmente. Mas você tá adicionando latência artificial, e gastando créditos de API à toa.

Com webhooks, você só processa quando algo acontece. Real-time de verdade. A carga no seu servidor é mínima porque você não fica batendo na API feito um relógio suíço quebrado. E convenhamos: integrações nativas são legais até o momento que você precisa de lógica customizada ou quer combinar dados de 3 sistemas diferentes. Aí você fica refém do que o marketplace permite.

Redução de Carga e Escalabilidade

Num cenário onde você tá processando 200 leads por dia, tanto faz. Mas e se você fizer uma campanha que traz 2.000 conversões num único domingo à tarde? Webhooks processam isso sem suar. Cada evento dispara independente, sem criar uma fila gigantesca que vai te deixar 6 horas atrasado.

Você provavelmente já sabe disso.

Pré-requisitos Técnicos da Integração

Acessos e Permissões no RD Station

Você vai precisar de perfil de Administrador ou pelo menos Gerente dentro do RD Station Marketing. A área de integrações não aparece para perfis básicos, então se você não tem acesso, já vai negociando com quem tem.

O Endpoint do Agilux (Callback URL)

Dentro do painel do Agilux Engage Squad, você gera uma URL exclusiva para receber esses webhooks. É tipo `https://webhook.agilux.net/inbound/12abc34def567`. Guarda essa URL com carinho porque você vai colar ela no RD daqui a pouco.

Ah, e obviamente você precisa de uma conta Agilux ativa com permissão para Inbound Webhooks. Se você tá no plano básico, pode ser que precise dar upgrade. Vale checar antes de começar.

Documentação de Apoio

Eu sempre deixo as docs abertas enquanto configuro. A RD Station API v2 tem detalhes sobre os códigos de status HTTP (200, 400, 500) que você vai precisar interpretar quando testar a integração. A documentação oficial do RD sobre webhooks também explica bem a estrutura do JSON que eles enviam. E acredite, os campos mudam dependendo do tipo de evento que você configurar.

Passo a Passo: Configurando o Webhook de Saída no RD Station

Criando o Webhook no Painel

Você entra no RD Station, vai em Integrações > Webhooks > Criar Webhook. Até aqui, tranquilo. Agora vem a parte que importa: escolher o gatilho certo.

Você pode disparar o webhook em vários momentos: conversão, mudança de estágio, oportunidade criada. Para qualificação de leads em tempo real, normalmente você quer “Conversão” ou “Oportunidade”, dependendo de onde no funil você quer que a IA entre.

Se você configurar para disparar em toda conversão, incluindo materiais ricos de topo de funil (tipo “baixar e-book sobre tendências de 2024”), vai processar muito lead frio. Não é erro, mas pode não valer a pena.

Filtrando Eventos Específicos

Aqui você precisa pensar estrategicamente. O RD deixa você filtrar por tipo de conversão ou por tags. Se você só quer que o Agilux processe leads que pediram “Demo” ou “Orçamento”, configura o webhook para disparar apenas nessas conversões específicas.

Isso economiza processamento e foca a Qualificação de Leads Automatizada onde realmente importa: nos leads com intenção comercial clara. Ninguém precisa de IA conversando com alguém que só baixou um PDF sobre “5 dicas de marketing”. (Okay, você provavelmente já sabia disso.)

Na prática, você vai até a seção de filtros e seleciona os formulários ou eventos específicos. Se o RD não der essa granularidade diretamente, você pode usar tags como proxy, tipo marcar conversões de fundo de funil com uma tag “webhook_agilux” e disparar o webhook só quando essa tag aparecer.

Estrutura e Exemplo do JSON Payload

Anatomia do Objeto JSON do RD Station

O Webhook RD Station manda um POST com um JSON mais ou menos assim. Campos padrão incluem `uuid` (um identificador único do lead), `email` (sua chave primária para não duplicar), e `first_conversion`, que traz dados da origem, como canal, campanha, página de conversão.

Você também recebe `personal_data` com nome, telefone, cargo. E o campo `custom_fields`, que é onde mora a mágica: orçamento estimado, número de funcionários, tecnologias que usa, tudo que você capturou no formulário customizado.

Exemplo Real de Código

Aqui vai um exemplo típico do que o RD envia:

“`json
{
“leads”: [
{
“uuid”: “a1b2c3d4”,
“email”: “lead@empresa.com.br”,
“personal_data”: {
“name”: “Engenheiro Silva”,
“job_title”: “CTO”
},
“custom_fields”: {
“orcamento”: “50k-100k”,
“tecnologia_atual”: “Zapier + Make”
},
“first_conversion”: {
“source”: “google”,
“content”: “cpc-demo”
}
}
]
}
“`

Limpo. Estruturado. Fácil de parsear.

Mapeando Campos Personalizados (Não Pule Isso)

A parte que mais dá problema é o nome dos `custom_fields`. Se no RD você criou um campo chamado “orçamento-estimado” com hífen, mas no Agilux você configurou “orcamento_estimado” com underscore, o mapeamento quebra silenciosamente. A IA vai receber `null` naquele campo e você não vai entender por que ela não tá personalizando a abordagem.

Antes de ir live, valida a nomenclatura. Abre o JSON real que o RD tá enviando (dá pra ver isso nos logs de teste) e confere se os nomes batem exatamente com o que você configurou no Agilux.

Configuração de Recebimento no Agilux Engage Squad

Parsing e Ingestão dos Dados

Dentro do Agilux, você vai na seção de Inbound Webhooks e configura como o sistema deve ler o JSON que chega. A interface normalmente mostra um preview do payload e deixa você arrastar campos para mapear variáveis.

Você pega o `email` e mapeia para a variável `lead_email`. O `personal_data.name` vira `lead_nome`. O `custom_fields.orcamento` vira uma variável de contexto que a IA vai usar na conversa.

Esse mapeamento é crítico porque é ele que alimenta o cérebro do agente.

Definindo o Prompt Inicial da IA

Aqui é onde a Automação de Marketing AI começa a fazer sentido. Você configura o prompt que o agente vai usar para iniciar a conversa. Algo tipo:

> “Você recebeu uma solicitação de demo de {{lead_nome}}, que é {{job_title}} na empresa. O orçamento indicado foi {{orcamento}}. Inicie a conversa de forma consultiva, perguntando sobre os desafios atuais com automação de marketing.”

Vê como os campos mapeados aparecem entre chaves? O Agilux substitui isso pelos valores reais antes de processar. Se você mapear errado, o agente vai falar “Oi {{lead_nome}}” literalmente, e o lead vai achar que você é um robô mal configurado. O que, bom, tecnicamente seria verdade.

Personalizando a Abordagem por Contexto

Dá para ir além. Se o campo `tecnologia_atual` mostrar “nenhuma”, o prompt pode instruir o agente a ter uma abordagem educativa. Se mostrar “Zapier + Make”, o agente pode assumir maturidade técnica e já falar de integrações avançadas.

Isso não é inteligência artificial genérica. É contextualização pesada baseada em dados estruturados.

Lógica de Qualificação e Retorno de Dados

Como a IA Faz a Triagem Real

O Agilux recebe o lead, dispara a mensagem inicial via WhatsApp ou email, e começa uma conversa. A IA faz perguntas de qualificação, como orçamento, timing, autoridade, necessidade, tipo um BANT automatizado, mas sem parecer um interrogatório policial.

Se o lead responde e demonstra fit, a IA marca como qualificado. Se o lead some ou claramente não tem orçamento/timing, marca como “nurture”. Tudo isso acontece enquanto o lead ainda lembra que preencheu o formulário.

Fechando o Loop: Atualização no CRM

Aqui vem uma parte que muita gente esquece. Honestly, eu vejo isso acontecer com frequência assustadora. Depois que o Agilux qualifica ou desqualifica o lead, você precisa voltar essa informação pro RD Station (ou pro CRM conectado a ele).

O Agilux pode fazer isso usando a RD Station API v2 para adicionar uma tag tipo `qualificado_agilux` ou `desqualificado_ia`. Ou mover o lead para outro estágio do funil automaticamente.

Esse loop de feedback é essencial. Sem ele, você tem dois sistemas operando em paralelo sem conversar, e o time de vendas fica perdido sem saber qual lead já foi trabalhado.

Monitoramento, Logs e Troubleshooting

Validando Se a Conexão Funciona

Primeira coisa: depois de configurar o webhook, dispara um teste. O RD tem um botão “Enviar Teste” que manda um payload fake. Você vai ver nos logs do Agilux se chegou e se retornou `200 OK`.

Se não aparecer nada, ou se retornar erro 400/500, tem algo errado. Ferramentas tipo RequestBin ou Webhook.site são ótimas para debugar. Você substitui temporariamente o endpoint do Agilux pela URL deles e vê exatamente o que o RD tá enviando.

Erros Comuns (E Como Consertar)

Timeout da requisição: Se o Agilux demora mais de 30 segundos para responder, o RD cancela o POST. Isso acontece quando você configurou processamento muito pesado no endpoint. Solução: processar de forma assíncrona e retornar 200 imediatamente.

Formatação errada no JSON: Às vezes o RD envia campos nulos ou usa arrays quando você esperava string. Valida o schema antes de ir pra produção. Eu já vi integração quebrar porque um campo de telefone veio como array em vez de string, num caso de um e-commerce de moda em SP que testamos em março.

Disparos duplicados: Se o RD tentar reenviar um webhook que falhou, você pode acabar processando o mesmo lead duas vezes. Implementa idempotência usando o `uuid` como chave única. Se já processou aquele uuid, ignora.

Primeiras 48 Horas: Fique de Olho

Eu sempre deixo os logs bem verbosos nas primeiras 48 horas. Qualquer coisa estranha que apareça nesse período normalmente indica um edge case que você não considerou, tipo leads sem telefone, ou campos personalizados com caracteres especiais que quebram o parser.

É chato ficar monitorando.

Anyway, essa integração não é complexa demais se você seguir o fluxo certo. Mas exige atenção nos detalhes, especialmente no mapeamento de campos e na validação dos payloads. E sobre aquele ponto de latência que mencionei no início? Faça isso bem e você vai ter leads sendo qualificados enquanto ainda estão empolgados. Isso muda tudo.