O fim do Zapier

O Zapier é um produto genial resolvendo um problema que não deveria existir.

Pense no que ele realmente faz. Ele existe porque o Mailchimp e o Webflow não se conhecem; porque o seu CRM e o seu transacional não se conhecem; porque cada ferramenta do seu stack carrega um banco privado e uma API, e alguém precisa ficar no meio traduzindo. O Zapier é esse alguém. Ele é a cola entre ferramentas que foram desenhadas para serem ilhas.

E cola, por melhor que seja, tem três propriedades inescapáveis: ela é uma camada a mais, ela custa, e ela seca e descola. Este artigo é sobre por que o produto Flows da LaunchWithAgency não tenta ser uma cola melhor — ele torna a cola desnecessária.

A diferença entre automação-cola e automação-nativa

Existem duas coisas profundamente diferentes que se chamam "automação", e confundi-las é a raiz do problema.

A automação-cola é a do Zapier: ela conecta dois sistemas externos. O gatilho vem de fora (um webhook do Webflow), e a ação vai para fora (uma chamada de API ao Mailchimp). A automação não tem dados próprios — ela só carrega dados de uma ilha para outra. Para fazer isso ela precisa de credenciais de ambos os lados, precisa saber o formato de campo de ambos os lados, e precisa torcer para que nenhum dos dois lados mude nada. Ela é, por definição, frágil: depende de duas APIs que ela não controla.

A automação-nativa opera dentro do próprio sistema. Quando o gatilho e a ação acontecem no mesmo banco, a automação não está transportando dados entre ilhas — ela está reagindo a um fato e produzindo outro, na mesma base. Não há credenciais de terceiros, não há formato de campo a negociar, não há API externa que possa mudar. A automação não é cola entre produtos; ela é uma operação a mais sobre os dados que já estão ali.

Flows é automação-nativa. E isso só é possível por causa da decisão de arquitetura que sustenta a suíte inteira: o banco único.

Como o Flows é construído

O Flows é deliberadamente pequeno. Ele tem três conceitos, e os três cabem em uma frase: um gatilho inicia uma execução, que roda uma sequência de passos em ordem.

O gatilho pode ser de três tipos. Um webhook — uma URL pública que, ao ser chamada, inicia o flow; útil para um formulário externo ou um sistema de terceiros que você ainda usa. Um agendamento (cron) — o flow roda a cada minuto, hora, dia ou semana. E — o tipo mais interessante — um evento interno: o flow dispara quando algo acontece dentro da própria suíte.

Esse último tipo é o coração da história. Quando alguém assina a sua newsletter, o produto News não chama uma API externa nem dispara um webhook para o mundo. Ele registra um evento interno — newsletter.subscribed — em uma tabela do mesmo banco, flow_events. E, no mesmo instante, o sistema tenta casar esse evento com os flows que estão escutando por ele. Não há uma viagem pela internet, não há uma fila de terceiros, não há latência de webhook. O evento e a reação vivem no mesmo arquivo.

A execução é registrada na tabela flow_runs. Cada vez que um flow dispara, nasce uma linha ali: o payload que iniciou a execução, o status (running, succeeded, failed), o horário de início e fim, e — crucialmente — um log passo a passo em stepLogsJson, com a saída e o eventual erro de cada passo. Quando algo dá errado, você não está adivinhando: o histórico inteiro de cada execução está no banco, inspecionável.

Os passos são quatro tipos, e a escolha de parar em quatro é uma decisão de produto, não uma limitação. Enviar um email. Fazer uma chamada HTTP. Esperar um delay. Avaliar uma condição (if) e ramificar. Esses quatro cobrem a esmagadora maioria das automações de marketing real: "quando entrar um lead, espere um dia, mande o email de boas-vindas, e se ele abriu, mande o segundo". Não há um catálogo de quinhentos conectores porque não há quinhentas ilhas para conectar — há um banco, e os passos operam sobre ele.

O que some quando a cola some

A consequência prática de trocar automação-cola por automação-nativa é que uma classe inteira de problemas deixa de existir.

Some o ponto de falha externo. Um Zap quebra quando uma API de terceiro muda. Um flow que reage a newsletter.subscribed não pode quebrar por isso — não há API de terceiro envolvida. O evento é uma linha numa tabela; o flow é uma consulta a essa tabela. Para isso quebrar, o banco teria que quebrar — e nesse ponto você tem problemas maiores que uma automação.

Some a latência de transporte. A automação-cola tem que esperar: o webhook viaja, a fila do Zapier processa, a chamada de API volta. A automação-nativa reage no mesmo processo que gerou o evento.

Some a credencial frágil. Não há token de API do Mailchimp para expirar, nem permissão do Webflow para revogar. O flow opera no banco ao qual ele já pertence.

Some a fatura separada. A automação não é um quinto fornecedor cobrando por tarefa executada. Ela é uma capacidade da suíte que você já tem.

> O Zapier cobra por tarefa porque cada tarefa é uma travessia cara entre dois mundos. Quando não há dois mundos, não há travessia — e não há o que cobrar por ela.

Quando você ainda vai querer um webhook

Honestidade: o gatilho de webhook do Flows existe justamente porque o mundo não é só a LaunchWithAgency. Você ainda pode ter um sistema externo legítimo — um checkout, uma ferramenta de suporte, um produto interno — que precisa iniciar uma automação. O Flows recebe esse webhook de bom grado.

A diferença é de direção e de quantidade. No stack fragmentado, o webhook é a regra: toda comunicação entre produtos é uma travessia. No Flows, o webhook é a exceção — a ponte para o que ainda está fora da suíte. Dentro da suíte, a comunicação não atravessa nada, porque não há fronteira a atravessar.

Esse é o sentido exato de "o fim do Zapier". Não é que automação deixou de ser necessária — ela é mais necessária do que nunca. É que a automação parou de ser um produto de cola comprado à parte e virou o que ela deveria ter sido desde sempre: uma propriedade nativa do sistema onde os dados já moram.