# Como conectar a túa web con Make ou Zapier sen crear unha bomba de reloxería Source: https://baqueiro.es/gl/automatizacion/conectar-web-make-zapier-sen-problemas/ Published: 2026-06-03T07:36:00+00:00 Updated: 2026-06-03T07:36:00+00:00 Author: Baqueiro Desarrollo Web Language: gl-ES Usage: Atribución requirida: permítese a cita cunha ligazón visible de volta --- **TL;DR** - Make e Zapier son moi útiles para prototipos e procesos sinxelos, pero escalan mal cando medra a complexidade. - Sen control de versións nin probas, os fluxos complexos vólvense fráxiles e caros de manter. - Pódense usar sen risco se documentas, vixías os erros e sabes cando pasar a código propio. ## O cliente con 147 Zaps e 23 fallando en silencio Unha empresa pediunos auditar as súas automatizacións. Tiña 147 Zaps en Zapier e 23 fallaban en silencio cada semana. Ninguén sabía cales eran críticos para o negocio. A factura mensual superaba os 800 €. E cando intentaron pasar a Make para aforrar, descubriron que os fluxos estaban tan enredados que a migración levaría meses. Make e Zapier son ferramentas lexítimas, pero funcionan como a pistola de silicona quente: ideais para prototipos rápidos, perigosas para estruturas permanentes. A facilidade para crear fluxos agocha o difícil que é mantelos. ## Que son realmente estas ferramentas Make (antes Integromat) e Zapier son plataformas que conectan aplicacións mediante fluxos visuais: cando pasa algo nunha ferramenta (chega un formulario, págase un pedido), execútanse accións noutras. Zapier é máis sinxela; Make é máis potente e flexible. As 2 cobran polo uso: Zapier por “tarefas” e Make por “créditos” (antes chamábaos “operacións”), que na práctica dependen dos pasos que se executan en cada fluxo. Con pouco volume son baratas. Con moito volume ou con fluxos complexos, encarécense axiña. Son ferramentas de orquestración, non de procesamento: delegan o traballo nas API dos servizos conectados e, se un falla, o fluxo herda o fallo. ## Cando usar Make ou Zapier (e cando non) **Casos axeitados:** - Prototipar integracións axiña para validar se de verdade fan falta. - Fluxos sinxelos de 2 ou 3 pasos entre servizos populares. - Volume baixo ou moderado (como orientación, menos de 10.000 créditos ou tarefas ao mes). - Equipos sen desenvolvedores que precisan unha solución inmediata. - Procesos que cambian a miúdo e precisan iterar rápido. **Casos problemáticos:** - Lóxica complexa con condicións aniñadas, bucles e xestión de erros. - Fluxos críticos para o negocio, onde unha caída sae cara. - Volume alto (por riba de 100.000 créditos ou tarefas ao mes), onde o custo se dispara. - Integracións con API pouco comúns ou inestables. - Procesos que esixen transformacións de datos complexas. A regra xeral: se o teu fluxo ten máis de 10 pasos, precisa lóxica condicional complexa ou manexa datos sensibles, probablemente debería ser código e non no-code. ## Antipatrón: a bolsa de nós Consiste en crear fluxos cada vez máis complexos sen recoñecer que superaches a capacidade da ferramenta. Os síntomas: - Fluxos de máis de 20 pasos con varias ramas condicionais. - Pasos de código (JavaScript ou Python dentro de Make ou Zapier) para resolver lóxica complexa. - Fluxos que chaman a outros fluxos e crean dependencias circulares. - Variables globais ou almacéns temporais para manter o estado entre execucións. Se chegaches aquí, estás a forzar a ferramenta. É como usar Excel como base de datos: pódese, pero non se debe. **Solución:** migrar a código. Un pequeno servizo en AWS Lambda ou un script PHP no teu propio servidor pode substituír 50 pasos de Zapier por código lexible, versionado e que se pode probar. ## Seguridade e datos sensibles Make e Zapier teñen acceso aos teus datos: de clientes, financeiros e operativos. Convén revisar 4 cousas. **Permisos de lectura e escritura.** Moitas conexións piden permisos de escritura cando só precisan ler. Revisa os permisos (scopes) de cada conexión e quita os que sobran. **Datos en tránsito e en repouso.** Estas plataformas procesan os teus datos nos seus servidores. Onde? Canto tempo se gardan? Zapier procesa os datos principalmente nos Estados Unidos; Make ofrece a opción de aloxar a túa conta en servidores da UE. Se manexas datos persoais ou información financeira regulada, comproba que encaixa coas túas obrigas do RXPD. **Credenciais compartidas.** As conexións adoitan usar chaves de API ou contas de servizo. Se alguén con acceso a Make ou Zapier deixa a empresa, que acceso conserva? Cando haxa cambios no equipo, revisa os usuarios e rota as chaves. **Rexistro de datos.** Por defecto, as 2 plataformas gardan un historial de execucións cos datos procesados: correos de clientes, datos persoais, importes. Revisa as opcións de retención e privacidade do teu plan (en Make, por exemplo, podes marcar un escenario como confidencial para que non garde eses datos). Case ninguén o fai. ## Custos: a trampa do escalado O modelo de prezos é adictivo con pouco volume e doloroso con moito volume. Zapier cobra por tarefas: cada acción que se executa correctamente conta como unha. Un fluxo con 5 accións que se executa 1.000 veces ao mes son 5.000 tarefas. O plan gratuíto inclúe 100 tarefas ao mes, e os de pago soben de prezo por tramos de volume. Make cobra en créditos: cada módulo que se executa consume polo menos 1, incluído o disparador que comproba periodicamente se hai datos novos, aínda que non os haxa. Adoita saír máis barato ca Zapier, pero a lóxica é a mesma: máis pasos e máis execucións, máis factura. **O problema:** ao crear un fluxo case ninguén calcula o volume real. Un formulario de contacto con tráfico medio, máis o spam, máis as comprobacións periódicas, pode xerar miles de créditos ou tarefas ao mes. O que deseñaches no plan gratuíto, de súpeto, custa 150 € ao mes. **Solución:** estima o volume antes de deseñar. Multiplica as execucións previstas polos pasos e engade unha marxe. Se o fluxo vai superar as 50.000 créditos ou tarefas ao mes, avalía alternativas como código propio ou n8n autoaloxado. ## Dependencia do provedor e migración Os fluxos de Zapier non se poden importar en Make, e os de Make expórtanse nun formato propio (blueprint) que só entende Make. Se soben os prezos, eliminan un plan ou cambian as súas condicións, estás atrapado. **Como mitigalo:** - Documenta os fluxos con independencia da ferramenta: que entra, que sae e que lóxica se aplica. Sen esa documentación, cada fluxo é unha caixa negra; contámolo en detalle en [o custo oculto das automatizacións mal documentadas](https://baqueiro.es/gl/automatizacion/custo-automatizacions-mal-documentadas/). - Para os fluxos críticos, ten un plan de migración: como replicalos en código se chega o momento. - Valora alternativas como n8n, que podes aloxar ti mesmo, para os fluxos onde o control é prioritario. ## Boas prácticas para fluxos robustos Se decides usar Make ou Zapier, faino ben: **1. Nomes descritivos.** “Zap #47” non serve. “Formulario de contacto → CRM con deduplicación” explica que fai. **2. Xestión de erros explícita.** Define que pasa se un paso falla: reintentar?, avisar a alguén? Fallar en silencio é o máis perigoso. **3. Historial de cambios.** As 2 gardan un historial de versións básico, pero non é un control de versións de verdade: non hai revisións nin explicación de por que se cambiou algo. Anota os cambios á man (as capturas de pantalla axudan). **4. Probas sistemáticas.** Non deas por feito que funciona. Proba con datos reais, con casos límite e con erros de API simulados. **5. Monitorización.** Revisa o historial de execucións con regularidade e configura alertas cando a taxa de erro supere un limiar. **6. Unha responsabilidade por fluxo.** Un fluxo fai unha cousa. Se precisas lóxica complexa, pregúntate se debería ser código. E lembra que conectar sistemas a base de parches crea outro tipo de silo: explicámolo en [o que gaña unha empresa cando os seus sistemas deixan de funcionar en silos](https://baqueiro.es/gl/automatizacion/silos-datos-empresa-conectar-sistemas-gl/). ## Alternativas que considerar Antes de comprometerte con Make ou Zapier, avalía: **n8n:** ferramenta de código dispoñible (con licenza fair-code, non estritamente open source) que podes aloxar no teu propio servidor. Máis barata a escala e con máis control, a cambio de manteres ti a infraestrutura. **Desenvolvemento a medida:** para fluxos críticos ou complexos, un pequeno servizo en PHP, Python ou Node é máis doado de manter, pódese probar e sae máis barato a longo prazo. Custa máis ao principio, pero despois só pagas o aloxamento, unha fracción do que custa un plan de pago de no-code. **Integracións nativas:** moitos CRM, pasarelas de pagamento e ferramentas de email márketing conéctanse entre si sen intermediarios (HubSpot con Stripe, por exemplo) ou teñen plugins oficiais para WordPress e WooCommerce. Antes de montar un fluxo, comproba se xa existe. ## Preguntas frecuentes **Make ou Zapier?** Make é máis potente e máis barato, pero custa máis aprendelo. Zapier é máis sinxelo e máis caro a escala. Para fluxos complexos, Make. Para o simple, Zapier. **Podo usar estas ferramentas nun comercio electrónico?** Para procesos auxiliares, si: notificacións, sincronizacións sinxelas de inventario, avisos ao equipo. Para o proceso de pagamento, non: é demasiado crítico e o volume pode ser alto. **Que fago se un fluxo falla constantemente?** Primeiro, identifica por que: cambiou unha API?, chegan datos inesperados? Despois, decide se paga a pena arranxalo ou se debería pasar a código. **Cumpren estas ferramentas o RXPD?** En xeral si, pero revisa a túa configuración: onde se procesan os datos, que gardan os historiais e se tes asinado o contrato de encargo do tratamento (artigo 28 do RXPD). Para datos moi sensibles, valora aloxar n8n no teu propio servidor. ## Conclusión Make e Zapier son útiles no seu sitio: prototipos rápidos, fluxos sinxelos, equipos sen desenvolvedores. Pero teñen límites claros que moitos descobren tarde. O risco principal non é a ferramenta, senón a tentación de seguir usándoa en casos cada vez máis complexos onde xa non encaixa. Recoñecer ese punto de inflexión e migrar a unha solución máis robusta é sensatez, non fracaso. Se tes fluxos nestas plataformas e queres saber cales están ben, cales deberían migrarse e como facelo sen romper nada, [escríbenos](https://baqueiro.es/gl/contacto/) e revisamos as túas integracións contigo.