El patron base tiene tres piezas: un emisor (la app que tiene el evento), una capa de orquestacion (que recibe, transforma y enruta) y un receptor (la app de destino via su API). Cuando la app de origen soporta webhooks —como Stripe con su evento checkout.session.completed— apuntas ese webhook a un endpoint propio o a un escenario de Make, validas la firma, mapeas los campos al esquema del destino (un CRM, Brevo, una base de datos) y haces el POST. Cuando la app de origen NO emite eventos, inviertes el flujo: un cron en VPS corre cada 5-15 minutos, pide a su API solo los registros nuevos (usando un cursor o timestamp guardado), y los empuja al destino. La idempotencia (evitar duplicados), los reintentos con backoff y un log persistente son lo que separa una integracion de juguete de una de produccion.
Toda integracion entre dos apps que no se hablan se reduce a la misma anatomia de tres piezas. El emisor es la app donde ocurre el evento (un pago en Stripe, un form enviado, una fila nueva en una planilla). El orquestador es la capa que recibe ese evento, lo transforma y decide a donde mandarlo. El receptor es la app de destino, a la que llegas siempre por su API.
El error clasico es intentar conectar emisor y receptor directo. Funciona en la demo y se rompe en produccion: no hay donde validar, transformar ni reintentar. La capa intermedia existe justamente para eso. Puede ser un escenario de Make.com (visual, rapido de armar) o un endpoint propio en Python sobre un VPS (control total, costo fijo).
Dentro del orquestador siempre hacen falta cuatro pasos: validar que el evento es legitimo (firma del webhook), mapear los campos del esquema de origen al de destino, ejecutar la llamada a la API de destino, y registrar el resultado en un log. Si separas estos cuatro pasos desde el dia uno, debuggear deja de ser adivinar.
La primera pregunta tecnica ante cualquier integracion es: la app de origen emite webhooks? Si la respuesta es si, ese es el camino. Un webhook es un POST que la app dispara hacia tu URL en el instante en que pasa el evento. Es eficiente (cero latencia, cero consultas vacias) y es la opcion correcta siempre que exista.
Si la app de origen NO tiene webhooks —pasa con muchos CRMs viejos, ERPs y herramientas internas— se usa polling: un proceso programado consulta la API de origen cada cierto intervalo y detecta lo nuevo. La pieza critica del polling es el cursor: guardas el timestamp o el ID del ultimo registro procesado, y en cada corrida pedis solo lo posterior. Sin cursor, reprocesas todo el historico cada vez y generas duplicados.
Implementacion concreta del polling: un script Python en un VPS con cron. La linea de crontab */10 * * * * /opt/sync/venv/bin/python /opt/sync/pull.py corre cada 10 minutos. El script lee el cursor desde un archivo o tabla, pagina la API de origen filtrando por updated_after=cursor, normaliza y hace UPSERT en el destino, y al final persiste el nuevo cursor.
Este es el caso de la query EN ("connect Stripe API with a CRM to automate client onboarding") y uno de los pedidos mas comunes. El flujo de produccion completo:
checkout.session.completed (o invoice.paid para suscripciones recurrentes). Stripe te da un secret whsec_....Stripe-Signature y verificarla con el secret antes de tocar nada. Si no valida, devolves 400 y cortas. Esto evita que alguien falsifique altas.event.id (evt_...), chequear si ya esta en tu tabla de eventos procesados; si esta, devolver 200 y salir. Stripe reenvia ante timeouts y sin esto duplicarias el cliente.La regla de oro: responder 200 a Stripe rapido. Si el procesamiento es pesado, encolalo y devolve 200 ya; sino Stripe interpreta timeout y reintenta, multiplicando el trabajo.
No hay una respuesta universal; hay un criterio. Make.com brilla cuando el flujo tiene muchos conectores listos (Stripe, Brevo, Google, Slack), el volumen es bajo o medio, y queres ver y editar la logica de forma visual sin desplegar nada. Armas el escenario, conectas las cuentas y queda corriendo. El costo escala por operaciones, asi que a alto volumen se encarece.
Un endpoint propio en Python sobre VPS conviene cuando: necesitas logica condicional fina que los modulos visuales hacen incomoda, el volumen es alto y queres costo fijo, manejas datos sensibles que preferis no rutear por un tercero, o vas a hacer transformaciones que requieren librerias especificas. El precio es que vos mantenes el servidor, los certificados y los logs.
En la practica muchos sistemas son hibridos: Make.com para los flujos de marketing y conectores estandar, y un par de endpoints Python en VPS para lo critico o de alto volumen. No es una decision de bando, es elegir la herramienta por flujo.
La diferencia entre una integracion que demos bien y una que aguanta meses sin tocarla esta en como maneja lo que sale mal. Estos son los puntos que mas se subestiman:
Tratar estos seis puntos desde el diseno es lo que convierte un cableado en infraestructura.
| Criterio | Webhook (push) | Polling con cron (pull) | Make.com (iPaaS) | |
|---|---|---|---|---|
| Requisito en la app de origen | Debe emitir webhooks nativos | Solo necesita API de lectura | Conector disponible o webhook/HTTP | |
| Latencia | Tiempo real (segundos) | Igual al intervalo del cron (5-15 min) | Tiempo real o por schedule | |
| Infraestructura propia | Endpoint HTTPS publico | VPS con cron + script | Ninguna (gestionada) | |
| Manejo de duplicados | Idempotencia por ID de evento | Cursor por timestamp/ID | Built-in parcial + filtros | |
| Costo a alto volumen | Bajo (solo tu servidor) | Bajo (costo fijo VPS) | Escala por operaciones, sube | |
| Velocidad de armado | Media (codigo + validacion) | Media (script + cursor) | Alta (visual, sin deploy) | Alta |
| Control sobre la logica | Total | Total | Limitado a los modulos | |
| Ideal para | Stripe, Calendly, GitHub | CRM/ERP sin webhooks | Marketing, conectores estandar | |
| Datos sensibles | Quedan en tu infraestructura | Quedan en tu infraestructura | Pasan por un tercero |
Pones una capa intermedia (Make.com o un endpoint propio) que recibe el evento de la app de origen y llama a la API de la app de destino. Si el origen emite webhooks, lo apuntas a esa capa; si no, usas polling con un cron que consulta su API cada X minutos y propaga lo nuevo.
Webhook siempre que la app de origen lo soporte: es tiempo real y no desperdicia consultas. Polling es el plan B cuando la app no emite eventos: corre un cron cada 5-15 minutos pidiendo solo los registros nuevos mediante un cursor guardado. Lo ideal en sistemas criticos es combinar ambos.
Con idempotencia. Guardas el event.id de Stripe (evt_...) en una tabla de eventos procesados y, si llega uno repetido, devolves 200 y lo ignoras. Stripe reenvia webhooks ante timeouts o errores de red, asi que sin esto cada reenvio crearia un cliente nuevo.
Solo si validas la firma. Stripe firma cada webhook con un secret (whsec_...) que viaja en la cabecera Stripe-Signature. Tu endpoint debe verificar esa firma antes de procesar nada; si no coincide, rechazas con 400. Sin validacion, cualquiera podria enviarte pagos falsos.
Make.com para flujos con conectores estandar, volumen bajo-medio y edicion visual sin deploy. Codigo propio en VPS cuando necesitas logica fina, alto volumen con costo fijo, o manejas datos sensibles que prefieres no rutear por un tercero. Muchos sistemas reales son hibridos.
Stripe dispara checkout.session.completed hacia tu endpoint; validas firma, deduplicas por event.id, creas/actualizas el contacto en el CRM o Brevo por email, lo metes en la secuencia de bienvenida, y notificas a tu equipo por un bot de Telegram. Todo en una sola cadena.
Necesitas reintentos con backoff exponencial (esperar 1s, 4s, 16s...) y, si todo falla, mandar el evento a una cola de muertos para revisarlo despues. Sin esto, una caida breve del destino significa perder datos de forma silenciosa.
Un cron en VPS corre el script cada X minutos: lee el ultimo cursor guardado, pagina la API de origen filtrando por updated_after=cursor, normaliza los campos y hace UPSERT en Postgres o SQLite, y al final persiste el nuevo cursor. El cursor es lo que evita reprocesar todo el historico.
Para alertas internas en tiempo real. Con un POST al metodo sendMessage de su API mandas notificaciones (alta de cliente, error en un flujo, pago grande) que llegan al celular de tu equipo en segundos. Es mas barato y rapido de cablear que el email transaccional.
Si, siempre que la app tenga una API REST. Usas el modulo HTTP generico para llamar a su API directamente, o armas un endpoint propio. La ausencia de un conector pre-hecho no es un bloqueo; es solo un poco mas de trabajo de mapeo manual.
Diagnóstico de 15 minutos, sin compromiso. Un operador, no una agencia.
Agendar diagnóstico →