Integrar várias APIs de terceiros em uma camada de dados coerente é um desafio de design. API Integration Pipeline conecta Hablla, Zoho Creator, Zenvia Voice e API do SIGE ERP a tabelas do Supabase SQL, permitindo que as camadas de análise e relatórios evoluam sem buscar novamente os mesmos dados dos provedores.
Muitos projetos de integração de APIs começam mapeando os dados do provedor diretamente em um formato de relatório. Isso parece eficiente no início, mas combina a cobrança com a questão comercial atual. Quando o painel muda, a forma da API muda ou um novo modelo SQL é necessário, o sistema pode ter que extrair dados antigos novamente do provedor.
API Integration Pipeline adota a abordagem oposta. Os workers coletam payloads de Hablla, Zoho Creator, Zenvia Voice e API do SIGE ERP e, em seguida, armazenam-nas em tabelas SQL do Supabase/PostgreSQL. A camada de ingestão envolve apenas o payload com metadados operacionais, como external_id, tabela de destino, janela de execução e carimbos de data/hora.
Supabase disponibiliza PostgreSQL como uma camada de armazenamento operacional, para que cada integração possa chegar a um namespace SQL previsível. Tabelas como raw_contact_hablla, raw_events_hablla, raw_contact_telefonia, raw_events_faturado, raw_contact_sitee raw_events_agendamento são intencionalmente orientados para a fonte.
Isto dá ao sistema três vantagens. Primeiro, cargas antigas podem ser reprocessadas em novas tabelas de relatórios. Em segundo lugar, junções e enriquecimentos SQL podem ser testados sem solicitar os mesmos dados à API externa novamente. Terceiro, o desvio do esquema torna-se visível na camada bruta, em vez de ser silenciosamente achatado pela lógica de mapeamento inicial.
A ingestão agendada quase sempre repete janelas. Um worker pode buscar os últimos cinco dias de pedidos SIGE, os últimos sete dias de cartões Hablla, o mês atual e anterior de registros de agendamento Zoho ou uma janela recente de chamadas Zenvia. A repetição é saudável porque detecta atualizações atrasadas, mas somente se as gravações forem idempotentes.
O pipeline de ingestão bruta de APIs usa identificadores derivados de origem estáveis, como client-{id}, card-{id}, pedido-{Codigo}, lead-{ID}e agendamento-{ID}. Com a semântica upsert, a mesma janela pode ser executada novamente sem duplicar linhas. Essa é a diferença entre um sistema de ingestão reproduzível e uma stack crescente de registros duplicados.
Um servidor permanente nem sempre é a solução certa. Para esta carga de trabalho, GitHub Actions fornece execução agendada, replays manuais por meio de workflow_dispatch, segredos centralizados e logs de execução sem manter uma VM, uma plataforma de contêiner ou um worker sempre ativo.
O design da programação é prático: janelas pequenas e recentes são executadas com mais frequência, enquanto sincronizações maiores ou mais pesadas são executadas diariamente. Isso reduz a pressão do limite de taxa do provedor e reduz a chance de sobreposição de fluxo de trabalho. Ele também mantém o modelo operacional fácil de auditar porque cada fonte tem seu próprio fluxo de trabalho e histórico de execução.
A ingestão crua não significa que todas as fontes sejam tratadas de forma idêntica. Hablla os atendentes são coletados dia a dia porque os endpoints de resumo podem ser agregados por período. Zoho possui trabalhos completos e recentes para que o sistema possa atualizar registros recentes com frequência sem executar novamente janelas pesadas o dia todo. Os dados de chamadas Zenvia geralmente fazem mais sentido como uma coleta diária de fechamento do dia. Os dados de faturamento do SIGE também são coletados diariamente para janelas ERP previsíveis.
Essas escolhas são decisões de arquitetura, não trivialidades de implementação. O worker deve respeitar a semântica de cada API enquanto ainda produz um envelope de armazenamento bruto consistente.
O trabalho mais valioso do SQL geralmente acontece após o armazenamento bruto: junções entre Hablla cartões e pessoas, derivação de cronogramas de contato, visualizações de faturamento de SIGE, atribuição de leads de Zoho ou métricas de telefonia operacional de Zenvia. Manter essas transformações downstream significa que cada modelo SQL pode ser versionado, testado e substituído sem enfraquecer a confiabilidade da coleção.
Isto também torna o projecto uma continuação natural do antigo padrão de worker de integração mostrado na ETL Pipelines em workers de integração de APIs. A diferença é que API Integration Pipeline move o limite de armazenamento durável do Google Sheets para tabelas do Supabase SQL.
Os logs de fluxo de trabalho públicos ou semipúblicos nunca devem conter tokens, respostas completas de API, corpos de erro completos ou despejos de carga bruta. O pipeline de ingestão bruta de APIs mantém os logs operacionais: código de status, mensagem de erro resumida, contexto do provedor e resultado da execução. Isso é suficiente para diagnosticar a maioria das falhas sem expor dados confidenciais de clientes ou credenciais.
Adicionar outra integração segue um caminho repetível: criar um worker, definir a tabela bruta de destino, escolher a janela de coleta, preservar a carga bruta, definir um ID externo estável, adicionar segredos, criar um fluxo de trabalho e limpar logs. A arquitetura é escalável porque cada fonte tem complexidade local, mas o contrato de armazenamento permanece consistente.
Artigo do pipeline de ingestão bruta de APIs sobre ingestão bruta de APIs, workers Node.js, GitHub Actions ETL, tabelas brutas no Supabase SQL, arquitetura PostgreSQL, API da Hablla, API do Zoho Creator, API da Zenvia Voice, API do SIGE ERP, IDs externos idempotentes, pipelines de dados reproduzíveis e modelagem analítica downstream.