O que é um conector (integração) no dia a dia e quando a API entra
O botão nativo, o fluxo no Zapier ou Make e o contrato por baixo não são a mesma coisa. O lead do formulário continua no e-mail.
Na PME, conector é o plug pronto entre site, planilha, CRM e WhatsApp. Quando o menu nativo ou o catálogo do Zapier e do Make não cobrem o evento, o campo ou o sistema, a API deixa de ser ruído.

Segunda-feira, 9h14. A imobiliária abriu o escritório e o comercial pergunta pelo lead do formulário de ontem à noite: visita a um T2, telefone, nome. A planilha Leads está igual a sexta. O WhatsApp do grupo Comercial não tem o nome novo. Alguém diz: o conector caiu. Outra pessoa já está na documentação do site, a ler GET e token. O lead, entretanto, continua no e-mail do formulário, na caixa que ninguém trata como fila de trabalho.
Vocês estão a misturar três coisas com o mesmo nome. O botão nativo do produto. O fluxo no Zapier ou no Make. O contrato por baixo, o da API, que só aparece quando o menu não chega. Enquanto o nome não se separa, a segunda-feira gasta-se a reiniciar a coisa errada.
O que é um conector (integração) no dia a dia
No dia a dia da PME, conector e integração são o mesmo objeto na boca da equipe: um plug pronto entre dois programas que a casa já usa. Não é um projeto. É um cabo com forma. Você autoriza a conta, escolhe um evento (formulário enviado, linha nova, negócio ganho) e uma ação (criar linha, avisar o canal, mandar o WhatsApp). O menu traduz o contrato. Você não escreve o verbo. Você aponta para o que o catálogo já desenhou.
O ritual é sempre parecido. Na oficina, alguém liga a planilha de orçamentos ao Slack. Na imobiliária, o formulário do site à planilha e ao grupo do comercial. No fornecedor B2B, o CRM ao e-mail de “pedido novo”. Em todos os casos há quatro peças: o plug (o conector em si), a autorização (a conta Google, o WhatsApp Business, o CRM), o evento e a ação. Se uma destas quatro falha, o lead não anda. A frase “o conector caiu” junta as quatro num único culpado.
Isto não é um assistente a encaixar-se numa pasta ou num sistema. Esse encaixe é outro objeto, o MCP. Aqui o cabo é entre dois programas de trabalho: site, planilha, CRM, WhatsApp, e-mail. O conector não pensa. Ele só dispara o que o menu prometeu, com os campos que o menu mostrou.
Conector nativo, Zapier ou Make, e quando a API entra
A ordem prática na PME é esta, e não o contrário.
Conector nativo. O próprio produto oferece o botão. O site diz “enviar para Planilhas Google”. O CRM diz “ligar WhatsApp”. A planilha diz “avisar este canal”. Você autoriza, mapeia nome e telefone, liga. Não há ferramenta no meio. O dado sai de A para B no caminho que o fabricante desenhou. Se o evento que você precisa está nesse menu, este é o cabo mais curto. Na segunda-feira, é também o primeiro sítio a olhar: a conta ainda está autorizada? O envio do formulário está mesmo a passar por este botão, ou só por e-mail?
Zapier ou Make. O catálogo no meio. A e B não se falam sozinhos, mas ambos existem na prateleira da ferramenta. Você monta o fluxo: quando isto, faça aquilo. Paga-se a ferramenta, não o projeto. Serve quando o nativo não existe ou não chega ao segundo destino (planilha e WhatsApp, CRM e Slack, formulário e os dois). O menu continua a traduzir o contrato. A diferença é que agora há um terceiro a ver o dado passar.
Quando a API entra. O menu mente, ou cala. O evento não está no produto. O app não está no catálogo. Falta o campo (prazo no pátio, referência da peça, código da obra). Falta o verbo (criar ficha no sistema interno da oficina, não só uma linha no Sheets). Ou o dado não pode passar por um terceiro. Aí deixa de haver plug. Passa a haver contrato: a documentação com GET e token que alguém abriu na segunda-feira, cedo demais, antes de saber se o cabo nativo sequer estava ligado.
A API não é o passo seguinte por ser “mais profissional”. É o passo seguinte quando o plug pronto não cobre o pedido. Se o pedido cabe no botão nativo, a API é ruído. Se cabe no catálogo do Zapier ou do Make, a API ainda é ruído. Só deixa de ser ruído quando o menu não tem o evento, o campo, o sistema, ou a casa não quer o dado a atravessar uma ferramenta no meio.
Três sincronizações: pedido e o que a ferramenta devolve
Conector nativo. Imobiliária. O formulário de visita no site tem, nas definições, “enviar respostas para Planilhas Google”.
O pedido (a configuração): autorizar a conta Google da agência, escolher a planilha Leads, mapear nome, telefone, e-mail, imóvel de interesse, bairro. Ligar. A equipe trata isto como “o conector do site”.
O que a ferramenta devolve: numa manhã boa, uma linha nova com data e hora, e o comercial vê o T2 antes do café. Numa manhã má, o produto mostra “Google Sheets desconectado, faça login novamente”, ou o envio corre só para o e-mail do formulário porque o botão nativo nunca foi o caminho real: alguém testou o e-mail, gostou, e o mapeamento da planilha ficou a meio. O comercial diz que o conector caiu. O lead está no e-mail do site desde domingo à noite.
Zapier ou Make. Oficina. A planilha Orçamentos já recebe o pedido (nome, telefone, matrícula, sintoma). O Slack do serviço é o sítio onde o encarregado realmente olha.
O pedido (a configuração): quando aparecer linha nova em Orçamentos, criar mensagem no canal #serviço com matrícula e sintoma, e mandar um WhatsApp ao mecânico de domingo com o telefone do cliente. Dois destinos, um evento. O nativo da planilha não fala com o WhatsApp. O catálogo do Zapier ou do Make fala.
O que a ferramenta devolve: execução verde, linha criada no histórico, aviso no canal, WhatsApp saído. Ou o contrário, concreto: app desconectado (a conta Google ou o WhatsApp Business expirou), campo em falta (o telefone veio vazio e o WhatsApp recusa), 401 (a autorização morreu no fim de semana), “este evento não existe no catálogo” (alguém escolheu “formulário enviado” num site que o catálogo só conhece como “linha nova na planilha”). O orçamento continua no e-mail do site. A planilha não mexeu. O Slack está calado. Reiniciar o Zapier não traz o lead se o evento real nunca foi o que o fluxo escuta.
Quando a API entra. Fornecedor B2B de peças para instalação. O comercial quer isto: cada pedido no formulário do site cria ficha no CRM interno (não o CRM da moda, o da casa, com stock e prazo no pátio) e avisa o WhatsApp com a referência da peça e o número da obra.
O pedido (a configuração): no menu nativo do site só existe “enviar por e-mail”. No Zapier e no Make o CRM interno não está no catálogo. O campo “prazo no pátio” não aparece em nenhum mapeamento. O evento que a equipe quer (“pedido com peça em falta no armazém”) não existe no produto do site.
O que a ferramenta devolve: o nativo devolve o e-mail de sempre. O Zapier ou o Make devolve “este evento não existe no catálogo”, ou uma lista de CRMs que não são o vosso. A documentação do CRM interno, essa, mostra o contrato: um pedido autenticado com token, os campos certos, a ficha criada. Aqui a API entra porque o plug pronto não tem o sistema, não tem o campo e não tem o verbo. Não entra porque alguém abriu a página do GET na segunda-feira por hábito.
Repare no padrão das três manhãs. O lead parado não prova que “a integração é frágil”. Prova que ninguém nomeou qual dos três cabos estava no caminho, e qual é que nunca esteve.
Como decidir em 5 minutos
Antes de pedir orçamento a um programador ou de colar um token na pressa, faça estas perguntas em voz alta. A resposta cabe no tempo de um café.
O evento existe no produto? Formulário enviado, linha criada, negócio ganho, peça em falta. Se o fabricante não dispara esse evento, o conector nativo não o vai inventar, e o Zapier só o ouve se o catálogo o tiver traduzido. Sem evento, não há cabo. Há e-mail.
O app está no catálogo? Site, planilha, Slack, WhatsApp, o CRM que vocês realmente usam. Se os dois lados estão no nativo, use o nativo. Se não estão no nativo mas estão no Zapier ou no Make, o meio chega. Se um dos lados é o sistema interno da oficina ou o stock do pátio, o catálogo não vai aparecer por insistência.
Falta campo, verbo ou sistema? Nome e telefone quase sempre passam. Referência da peça, prazo no pátio, código da obra, “criar ficha” em vez de “mandar linha”, muitas vezes não. O conector só move o que o menu mostrou. Campo que não está no mapeamento não chega ao comercial, mesmo com o fluxo “verde”.
O dado pode passar por um terceiro? Lead de visita, telefone de cliente, matrícula, número de obra. Se a casa não quer isto a atravessar uma ferramenta no meio, o nativo (A para B, sem escala) ou o contrato direto (API) são as duas saídas. O Zapier e o Make, neste ponto, saem da conversa por política, não por capricho técnico.
Se as quatro respostas cabem num botão do produto, ligue o nativo e teste com um lead vosso, não com o do cliente de domingo. Se cabem no catálogo e o terceiro é aceitável, monte o fluxo curto. Se uma das quatro falha, aí sim abre a documentação. Não antes.
Limites
O terceiro vê o dado. No Zapier e no Make, o lead, o telefone e a matrícula passam por uma casa que não é a vossa. Isso pode ser aceitável num orçamento de oficina e inaceitável numa lista de visitas com morada. O nativo reduz o número de olhares. Não o reduz a zero: o produto do site e a planilha também são casas.
O catálogo mente. “Integração WhatsApp” no ecrã do CRM pode significar aviso quando o negócio é ganho, não quando o formulário chega. “Ligado ao Sheets” pode significar as respostas novas daqui para a frente, não as de ontem. “Este evento não existe no catálogo” é a frase honesta. A frase perigosa é o ícone verde ao lado de um evento que não é o vosso.
O conector não inventa campo. Se o formulário não pede o bairro, a planilha não o ganha. Se o site não envia a referência da peça, o WhatsApp não a vai adivinhar. Pedir ao fluxo para “completar” o que o evento não trouxe é pedir outra coisa: regra, pessoa, ou um sistema que já tem esse dado.
“Caiu” muitas vezes é token ou campo. A autorização expirou no fim de semana. O WhatsApp Business desligou a conta. O telefone veio vazio. O e-mail do site continua a ser o único caminho que realmente dispara. Tratar isto como falha misteriosa do conector atrasa o único gesto útil: ver onde o lead está agora (quase sempre no e-mail) e qual dos três cabos é que a equipe julgava ter ligado.
A API não é medalha de profissionalismo. Usá-la para um mapeamento que o botão nativo já faz é pagar complexidade com o dinheiro da segunda-feira. Usá-la quando o menu não tem o sistema, o campo ou o verbo é o trabalho certo. A diferença não está no vocabulário. Está no pedido.
O que fazer agora
Hoje: abra a caixa de e-mail do formulário e tire o lead de domingo daí para a planilha e para o WhatsApp do comercial, à mão. Depois, no papel, escreva os três nomes em três linhas: botão nativo do produto, fluxo no Zapier ou Make, contrato da API. Marque qual deles a equipe acha que está ligado, e qual é que o e-mail prova que realmente dispara. Se ninguém souber, o conector não caiu. Ele nunca foi o caminho.
Nesta semana: escolha um único pedido de sincronização (formulário para planilha, planilha para Slack, CRM para WhatsApp) e teste com um envio vosso. Confirme o evento, a autorização e os campos. Se o nativo cobrir, fique no nativo. Se faltar o segundo destino e o catálogo o tiver, aí o Zapier ou o Make. Se faltar o sistema interno, o campo ou a permissão para o dado passar por terceiro, aí a documentação. Um cabo de cada vez. O lead da próxima segunda não precisa de três nomes. Precisa de um caminho que a equipe saiba nomear.