Uma instância de Mautic isolada tem valor limitado. O valor real aparece quando ela conversa com o resto: recebe contatos do site, sincroniza com o CRM, sabe quem comprou na loja e devolve informação para as equipes que precisam dela.

Essa conversa é o que transforma a ferramenta em operação — e é também o que mais gera problema depois, por um motivo específico: integrações falham em silêncio. Quando um formulário para de enviar contatos, ninguém recebe um erro. Os leads simplesmente deixam de aparecer.

Este guia trata do que as integrações exigem do servidor, de onde elas quebram e de como perceber antes que o prejuízo se acumule.

As formas de integrar

Três mecanismos, com comportamentos e exigências diferentes:

Mecanismo	Quem inicia	Uso típico
Formulários	O visitante	Captura no site
Chamadas de API	O outro sistema	Enviar ou buscar dados sob demanda
Webhooks	O Mautic	Avisar outro sistema quando algo acontece

A distinção entre os dois últimos importa, e o conceito está detalhado no artigo sobre o que é uma API:

Chamadas de API são iniciadas por quem precisa da informação. Um CRM que busca contatos novos a cada hora está fazendo isso. O custo é previsível e controlável.

Webhooks são iniciados pelo Mautic quando algo acontece — um contato entrou em um segmento, abriu um e-mail, preencheu um formulário. O custo depende do volume de eventos, e é aí que aparecem as surpresas.

O ponto que muda o dimensionamento: um webhook por evento, em uma base ativa, é muito mais tráfego do que a maioria imagina. Uma campanha disparada para dez mil contatos pode gerar dezenas de milhares de eventos em poucos minutos, se aberturas e cliques estiverem configurados para notificar.

O que isso exige do servidor

Quatro exigências concretas:

1. Capacidade para tráfego que não é de campanha

Integrações geram carga contínua, distinta da carga de processamento de segmentos e campanhas tratada no artigo sobre dimensionar um servidor para Mautic.

Um CRM que sincroniza a cada quinze minutos, um site que envia formulários o dia inteiro e webhooks disparando a cada evento somam um tráfego constante que precisa caber no dimensionamento — e que não aparece se você medir apenas as janelas de processamento.

2. Processamento fora do ciclo da requisição

Integrações que executam durante o atendimento de uma requisição prendem processos enquanto esperam o outro sistema responder.

Se o CRM estiver lento, o Mautic fica lento junto. O padrão correto é registrar o evento e processá-lo em segundo plano, como descrito no artigo sobre o que é uma fila de tarefas.

3. Repetição automática

Sistemas externos ficam indisponíveis temporariamente — manutenção, instabilidade, limite de requisições atingido. Uma integração sem repetição automática perde o evento definitivamente.

O padrão adequado: tentar de novo algumas vezes, com intervalo crescente, e registrar as falhas definitivas em algum lugar que alguém veja.

4. Endereço estável

Integrações costumam ser autorizadas por endereço de origem. Ao trocar de servidor, o endereço muda e as integrações param — sem que ninguém avise. É o mesmo alerta registrado no artigo sobre o que avaliar antes de contratar um servidor, e aqui ele tem consequência direta sobre a operação de marketing.

O problema dos contatos duplicados

A dor de cabeça mais comum em integrações de marketing, e ela merece seção própria.

Quando dois sistemas guardam informação sobre as mesmas pessoas, é preciso decidir como reconhecer que dois registros são a mesma pessoa. Sem essa decisão, duplicatas se acumulam.

As causas típicas:

• Critério de identificação diferente entre os sistemas — um usa e-mail, outro usa documento ou identificador interno.
• Variações do mesmo endereço, com maiúsculas, espaços ou pontuação diferente.
• A mesma pessoa com endereços diferentes em cada sistema.
• Sincronização nos dois sentidos sem regra de precedência, criando ciclos de atualização.

As consequências vão além da desorganização: duplicatas inflam a base, distorcem métricas e geram envios repetidos — a mesma pessoa recebendo a mesma mensagem duas vezes, o que prejudica a reputação de envio tratada no artigo sobre entregabilidade em automação de marketing.

O que resolve, e precisa ser definido antes de ligar os sistemas:

1. Um critério único de identificação, acordado entre os dois lados.
2. Normalização dos dados antes de comparar — remover espaços, padronizar maiúsculas.
3. Uma direção de precedência por campo: quem manda em cada informação quando os dois divergem.
4. Um processo de mesclagem para as duplicatas que já existem.
5. Verificação periódica, porque duplicatas voltam a aparecer.

O item 3 é o que evita o cenário mais frustrante: dois sistemas sobrescrevendo um ao outro indefinidamente, cada sincronização desfazendo a anterior.

Onde as integrações quebram

Um mapa dos pontos de falha, para saber onde procurar:

Falha	Sintoma
Credencial expirada	Integração para de funcionar sem aviso
Alteração na API do outro sistema	Erros a partir de uma data
Limite de requisições atingido	Falhas em horários de pico
Campo removido ou renomeado	Dados chegam incompletos
Mudança de endereço do servidor	Recusa de autorização
Dado em formato inesperado	Registros rejeitados
Sistema externo indisponível	Eventos perdidos sem repetição

A primeira linha é a mais frequente e a mais evitável: credenciais expiram em datas conhecidas, e manter um registro delas elimina essa categoria inteira de incidente.

A quarta merece atenção porque é traiçoeira: a integração continua funcionando, os registros continuam chegando, e um campo importante vem vazio. Ninguém percebe até alguém tentar usar aquele dado.

Monitorar o que não se anuncia

O ponto mais importante deste artigo.

Integrações de marketing têm uma característica cruel: quando param, o sintoma é a ausência de algo. Nenhum erro aparece na tela, ninguém recebe notificação, e a descoberta costuma acontecer semanas depois — quando alguém pergunta por que os leads caíram.

Nesse intervalo, oportunidades foram perdidas de forma irrecuperável: um formulário que não registrou contatos por três semanas não tem como recuperá-los.

O que monitorar:

• Volume de contatos recebidos por origem. Uma fonte que zerou é o sinal mais claro.
• Taxa de erro das chamadas de integração.
• Fila de eventos pendentes, cujo crescimento indica que o destino não está aceitando.
• Validade das credenciais, com alerta antecipado.
• Registro de falhas definitivas, revisado periodicamente.
• Comparação entre sistemas: o número de contatos de um período bate nos dois lados?

O primeiro item é simples e resolve a maior parte: um alerta quando uma origem que costuma trazer contatos diários fica algumas horas sem trazer nenhum transforma semanas de perda em horas.

O último é a verificação mais confiável, e vale como rotina mensal: se o site registrou duzentos formulários e o Mautic tem cento e oitenta contatos daquela origem, vinte se perderam em algum lugar.

Antes de ligar dois sistemas

Um roteiro que evita retrabalho:

1. Defina o que precisa fluir, em qual direção, e com que frequência. Nem tudo precisa ser em tempo real.
2. Escolha o critério de identificação de contatos.
3. Defina a precedência por campo.
4. Verifique os limites de requisições do outro sistema.
5. Teste com um volume pequeno antes de ligar a base inteira.
6. Configure a repetição automática e o registro de falhas.
7. Monte o monitoramento antes de considerar a integração pronta.
8. Documente: o que conecta o quê, com quais credenciais e quem é o responsável.

O passo 1 costuma reduzir o escopo pela metade. Nem toda informação precisa ser sincronizada, e cada campo sincronizado é um ponto a mais de falha e de conflito. Sincronizar o essencial é mais robusto do que sincronizar tudo.

O passo 8 resolve o problema que aparece quando alguém sai da empresa: integrações funcionando que ninguém sabe explicar, com credenciais de origem desconhecida.

Conclusão

Integrações são o que transforma uma instância de Mautic em operação de marketing, e trazem exigências específicas para o servidor: capacidade para tráfego contínuo, processamento em segundo plano, repetição automática e atenção ao endereço de origem quando o servidor muda.

Duas decisões tomadas antes de ligar os sistemas evitam a maior parte dos problemas: o critério de identificação de contatos e a precedência por campo — sem elas, duplicatas se acumulam e os sistemas passam a se sobrescrever.

E a medida que mais protege o resultado: alertar quando uma origem para de trazer contatos. Integrações falham em silêncio, e semanas de leads perdidos não se recuperam. Conheça o Cloud Server para Mautic da TBF Host e avalie o ambiente adequado à sua operação.

Perguntas frequentes

Qual a diferença entre API e webhook em uma integração?

A chamada de API é iniciada por quem precisa da informação — um CRM que busca contatos novos a cada hora, por exemplo —, com custo previsível. O webhook é iniciado pelo Mautic quando algo acontece, e o custo depende do volume de eventos, que em bases ativas pode ser muito maior do que se imagina.

Por que minha integração parou de funcionar sem aviso?

As causas mais comuns são credencial expirada, alteração na API do outro sistema, limite de requisições atingido ou mudança do endereço do servidor, que costuma ser usado para autorizar o acesso. Nenhuma delas gera erro visível — o sintoma é a ausência de dados chegando.

Como evitar contatos duplicados entre o Mautic e outro sistema?

Definindo antes de ligar os sistemas um critério único de identificação, normalizando os dados antes de comparar, estabelecendo uma direção de precedência por campo e mantendo um processo de mesclagem para as duplicatas existentes, com verificação periódica.

Meus sistemas estão se sobrescrevendo. O que fazer?

Falta definir a precedência por campo: quem manda em cada informação quando os dois lados divergem. Sem isso, cada sincronização desfaz a anterior indefinidamente. É a decisão que precisa ser tomada antes de ligar sincronização nos dois sentidos.

Integrações afetam o desempenho do servidor?

Sim, e de forma distinta do processamento de campanhas. Elas geram carga contínua ao longo do dia, que não aparece se você medir apenas as janelas de processamento de segmentos. Integrações que executam durante a requisição também prendem processos enquanto esperam o outro sistema responder.

Como saber se uma integração parou?

Monitorando o volume de contatos recebidos por origem. Um alerta quando uma fonte que costuma trazer contatos diários fica algumas horas sem trazer nenhum transforma semanas de perda em horas. Também vale comparar periodicamente os números entre os dois sistemas.

O que acontece com as integrações ao trocar de servidor?

Elas podem parar, porque muitas são autorizadas pelo endereço de origem, que muda com o servidor. A falha é silenciosa — nenhum sistema avisa. É um item que precisa estar na lista de verificação de qualquer migração.

Preciso sincronizar todos os campos entre os sistemas?

Raramente. Cada campo sincronizado é um ponto a mais de falha e de conflito. Definir o que realmente precisa fluir, em qual direção e com que frequência costuma reduzir o escopo pela metade — e sincronizar o essencial é mais robusto do que sincronizar tudo.