Integrar múltiples API de terceros en una capa de datos coherente es un desafío de diseño. API Integration Pipeline conecta Hablla, Zoho Creator, Zenvia Voice y API de SIGE ERP a las tablas de Supabase SQL, lo que permite que las capas de análisis e informes evolucionen sin tener que volver a buscar los mismos datos de los proveedores.
Muchos proyectos de integración de APIs comienzan mapeando los datos del proveedor directamente en un formulario de informe. Esto parece eficiente al principio, pero combina la recolección con la cuestión comercial actual. Cuando el tablero cambia, la forma de API cambia o se necesita un nuevo modelo SQL, es posible que el sistema tenga que extraer datos antiguos nuevamente del proveedor.
API Integration Pipeline adopta el enfoque opuesto. Los workers recopilan payloads de Hablla, Zoho Creator, Zenvia Voice y API de SIGE ERP, luego las almacenan en las tablas SQL de Supabase/PostgreSQL. La capa de ingesta solo envuelve la payload con metadatos operativos como external_id, tabla de destino, ventana de ejecución y marcas de tiempo.
Supabase hace que PostgreSQL esté disponible como una capa de almacenamiento operativo, por lo que cada integración puede aterrizar en un espacio de nombres SQL predecible. Tablas como raw_contact_hablla, raw_events_hablla, raw_contact_telefonia, raw_events_faturado, raw_contact_site, y raw_events_agendamento están intencionalmente orientados a la fuente.
Esto le da al sistema tres ventajas. En primer lugar, los payloads antiguos se pueden reprocesar en nuevas tablas de informes. En segundo lugar, las uniones y enriquecimientos de SQL se pueden probar sin volver a pedirle a la API externa los mismos datos. En tercer lugar, la deriva del esquema se vuelve visible en la capa sin procesar en lugar de ser silenciosamente aplanada por la lógica de mapeo inicial.
La ingestión programada casi siempre repite ventanas. Un worker puede recuperar los últimos cinco días de los pedidos de SIGE, los últimos siete días de las tarjetas Hablla, el mes actual y anterior de los registros de programación de Zoho o una ventana reciente de llamadas de Zenvia. La repetición es saludable porque detecta actualizaciones tardías, pero solo si las escrituras son idempotentes.
Raw API Ingestion Pipeline utiliza identificadores estables derivados de fuente, como client-{id}, card-{id}, pedido-{Codigo}, lead-{ID}, y agendamento-{ID}. Con la semántica upsert, la misma ventana puede volver a ejecutarse sin duplicar filas. Ésa es la diferencia entre un sistema de ingesta reproducible y una stack cada vez mayor de registros duplicados.
Un servidor permanente no siempre es la opción correcta. Para esta carga de trabajo, GitHub Actions proporciona ejecución programada y repeticiones manuales a través de workflow_dispatch, secretos centralizados y registros de ejecución sin mantener una máquina virtual, una plataforma de contenedores o un worker siempre activo.
El diseño de la programación es práctico: las ventanas pequeñas y recientes se ejecutan con más frecuencia, mientras que las sincronizaciones más grandes o más intensas se ejecutan diariamente. Esto reduce la presión del límite de tarifas del proveedor y reduce la posibilidad de superposición del flujo de trabajo. También hace que el modelo operativo sea fácil de auditar porque cada fuente tiene su propio flujo de trabajo e historial de ejecución.
La ingestión cruda no significa que todas las fuentes sean tratadas de manera idéntica. Hablla los asistentes se recopilan día a día porque los endpoints de resumen se pueden agregar por período. Zoho tiene trabajos completos y recientes para que el sistema pueda actualizar los registros recientes con frecuencia sin tener que volver a ejecutar ventanas pesadas durante todo el día. Zenvia los datos de llamadas a menudo tienen más sentido como recopilación diaria de cierre del día. Los datos de facturación de SIGE también se recopilan día a día durante períodos ERP predecibles.
Esas opciones son decisiones de arquitectura, no trivialidades de implementación. El worker debe respetar la semántica de cada API y al mismo tiempo producir un sobre de almacenamiento sin formato consistente.
El trabajo más valioso de SQL generalmente ocurre después del almacenamiento sin formato: uniones entre tarjetas Hablla y personas, derivación de cronogramas de contacto, vistas de facturación de SIGE, atribución de clientes potenciales de Zoho o métricas de telefonía operativa de Zenvia. Mantener esas transformaciones en sentido descendente significa que cada modelo SQL se puede versionar, probar y reemplazar sin debilitar la confiabilidad de la recopilación.
Esto también hace que el proyecto sea una continuación natural del antiguo patrón de integración de workers que se muestra en Pipelines ETL en workers de integración de APIs. La diferencia es que API Integration Pipeline mueve el límite de almacenamiento duradero de Google Sheets a las tablas de Supabase SQL.
Los registros de flujo de trabajo públicos o semipúblicos nunca deben contener tokens, respuestas API completas, cuerpos de error completos o volcados de payload sin procesar. Raw API Ingestion Pipeline mantiene los registros operativos: código de estado, mensaje de error resumido, contexto del proveedor y resultado de la ejecución. Esto es suficiente para diagnosticar la mayoría de las fallas sin exponer datos confidenciales de credenciales o clientes.
Agregar otra integración sigue una ruta repetible: crear un worker, definir la tabla sin procesar de destino, elegir la ventana de recopilación, conservar el payload sin procesar, definir una ID externa estable, agregar secretos, crear un flujo de trabajo y desinfectar registros. La arquitectura escala porque cada fuente tiene complejidad local, pero el contrato de almacenamiento sigue siendo consistente.
Artículo de pipeline de ingesta bruta de APIs sobre la ingesta bruta de APIs, workers de Node.js, tablas sin procesar de GitHub Actions ETL, Supabase SQL, arquitectura de PostgreSQL, API de Hablla, API de Zoho Creator, API de Zenvia Voice, API de SIGE ERP, IDs externos idempotentes, pipelines de datos reproducibles y modelado de análisis descendente.