Skip to main content

Automação de CEP no Pipefy: tentativa nativa vs. solução com middleware


Olá pessoal,

Queria compartilhar uma experiência curiosa que tive ao tentar automatizar o preenchimento de endereço a partir de um CEP dentro do Pipefy, utilizando a API pública do ViaCEP.

A ideia inicial era fazer tudo 100% dentro das automações do Pipefy, usando a ação “Make an HTTP request” e depois o gatilho “When an HTTP response is received” para atualizar os campos do card.

A configuração seguiu exatamente o que aparece em exemplos da comunidade:

Method: GET
URL: https://viacep.com.br/ws/[CAMPO_CEP]/json/
Authentication: None
Headers: não necessário
Content type: JSON
Request body: vazio

Também configurei o JSON schema com o retorno esperado da API (logradouro, bairro, localidade, etc.) para conseguir mapear os campos depois.

Testei vários cenários:

  • CEP vindo de campo dinâmico

  • CEP fixo na URL (ex: https://viacep.com.br/ws/01232000/json/)

  • campo CEP como texto

  • campo CEP como numérico

  • schema completo da resposta

Mesmo assim, os campos nunca eram preenchidos e não há logs claros para entender se a requisição foi executada ou não.

Depois de algumas tentativas, resolvi testar uma abordagem diferente: criar um pequeno middleware em Python (Flask).

O fluxo ficou assim:

  1. Pipefy dispara um webhook quando o card é criado

  2. O webhook envia card_id + CEP para um endpoint Flask

  3. O serviço consulta o ViaCEP

  4. O middleware processa o JSON retornado

  5. O próprio serviço faz uma mutation na API do Pipefy (GraphQL) para atualizar os campos de endereço do card

Resultado: funcionou imediatamente e de forma consistente.

Ou seja, acabamos criando uma espécie de “mini gateway de integração” só para fazer algo que teoricamente poderia acontecer dentro da própria automação.

Minha curiosidade é entender:

  • Existe alguma limitação conhecida no uso de HTTP request + HTTP response automations para esse tipo de cenário?

  • O comportamento pode estar relacionado ao fato dessas features ainda estarem em beta?

  • Existe alguma recomendação oficial de arquitetura para integrações simples com APIs externas?

No fim das contas, o processo gerou um pequeno “Frankenstein” de integração (Pipefy → Webhook → Flask → ViaCEP → GraphQL → Pipefy), que acabou funcionando muito bem.

Se alguém do time ou da comunidade tiver curiosidade sobre a implementação, fico feliz em compartilhar os detalhes.

Obrigado!

5 replies

Renata Lapetina
Community Manager
Forum|alt.badge.img

Sensacional a sua contribuição, ​@cris-elias! Obrigada por compartilhar sua solução com a Comunidade.
Seu relato é super valioso, principalmente por detalhar os testes que não funcionaram antes. É desse tipo de troca rica que a gente precisa por aqui. ✨ Valeu demais!


  • Author
  • Explorer
  • March 5, 2026

Valeu demais, ​@Renata Lapetina 😊

Fico feliz em contribuir e também em aprender com a comunidade. Esses testes que não funcionaram ajudaram a entender melhor a arquitetura, e pretendo seguir compartilhando avanços e resultados. Acho que essa troca faz diferença pra todo mundo.

Obrigado pelo retorno!


  • Explorer
  • October 18, 2026

Olá!

A sua experiência é muito comum ao trabalhar com automações HTTP nativas versus integrações via API/GraphQL no Pipefy.

Respondendo aos seus pontos sobre as limitações e arquitetura:

  1. Limitações das Ações HTTP Nativas: As automações nativas de requisição HTTP do Pipefy possuem algumas sensibilidades com respostas dinâmicas. Problemas comuns incluem a sanitização da string do CEP (se o usuário digitar com hífen 00000-000 vs apenas números 00000000), tratamento do Header de User-Agent (que algumas APIs públicas exigem para não bloquear a requisição) e o tempo de resposta/parsing estrito do schema JSON cadastrado.

  2. Arquitetura Recomendada (Webhook + GraphQL): O "Frankenstein" que você criou (Pipefy Webhook → Flask → API de CEP → Pipefy GraphQL) é, na verdade, a arquitetura de integração mais robusta e recomendada para ambientes de produção. O uso do GraphQL do Pipefy via cardFieldValues ou updateCardItem garante rastreabilidade, tratamento de exceções, formatação dos dados antes da inserção e tratamento de erros de API externa.

  3. Dica para Validação de Dados no Middleware: Quando for tratar o CEP no seu script em Python, lembre-se de sempre sanitizar a entrada (re.sub(r'\D', '', cep)) antes da consulta. Para testes de carga, validação de faixas de CEPs por estado, códigos IBGE e coordenadas geográficas durante o desenvolvimento do middleware, ferramentas de apoio como o CEP-BR (cep-br.com) são ótimas referências de dados.

Parabéns pela solução! O caminho via Webhook + GraphQL é o mais seguro para escalar processos no Pipefy.


  • Author
  • Explorer
  • October 18, 2026

Olá, Ronan!

Obrigado pela análise e pelas sugestões!

Curiosamente, tudo começou com uma provocação durante uma conversa com uma profissional de RH: “Como você não sabe o que é o Pipefy?!”. 😄

Resolvi conhecer a plataforma e, como estudo utilizando o plano gratuito, comecei a explorar os recursos disponíveis e entender até onde conseguiria chegar com eles. Foi nesse contexto que surgiu o desafio do preenchimento automático de endereços a partir de um CEP.

O mais interessante é que as limitações encontradas acabaram se tornando parte do aprendizado. Sem ter todos os recursos à disposição, precisei investigar alternativas, experimentar outras possibilidades e conectar ferramentas diferentes para chegar ao resultado desejado.

No fim, o Frank nasceu dessa combinação de curiosidade, experimentação e vontade de entender como as coisas funcionam por trás da interface.

Sua contribuição acrescenta pontos importantes a essa investigação, especialmente em relação à validação dos dados e aos cuidados necessários para evoluir uma prova de conceito para um ambiente de produção.

Obrigado por enriquecer a discussão! É muito bom ver um experimento que começou de forma tão despretensiosa continuar gerando aprendizado e troca de conhecimento na comunidade.


Se tiver curiosidade em conhecer a implementação, compartilho aqui o repositório do projeto:
https://github.com/criselias-dev/Frank-Orchestration-Engine


  • Explorer
  • October 18, 2026

Olá!

Sensacional a história de como o projeto nasceu! Muitas das melhores soluções e arquiteturas em TI surgem justamente dessa curiosidade de resolver um desafio prático e explorar os limites da ferramenta no plano gratuito.

Muito obrigado por compartilhar o repositório do Frank-Orchestration-Engine! Com certeza vai ajudar bastante outros membros da comunidade que estiverem tentando conectar o Pipefy com serviços externos e precisarem de uma referência prática em Python/Flask.

Vou dar uma olhada no código no GitHub. Parabéns pela iniciativa, pela documentação e por compartilhar o aprendizado com todos!

Abraços e bons estudos!