Cinco caminhos para levar dados de API ao Power BI — e o custo de cada um

Imagem de capa

Cinco trilhas partindo de um mesmo ponto e chegando a um mesmo destino, com espessuras diferentes.

Toda equipe de BI chega no mesmo ponto. O modelo de dados está pronto, os indicadores estão validados, o painel já é apresentado à diretoria. Então alguém pergunta se é possível incluir os dados do CRM.

O dado está lá. A API existe, está documentada e devolve o que foi solicitado. Só que a resposta honesta continua sendo a mesma: é possível, mas vai levar tempo.

Não é falta de competência do seu time. Manter uma integração de API no ar todo dia é trabalho de engenharia de dados, não de análise. Autenticação que expira, resultado partido em páginas, limite de chamadas, estrutura de dados que muda sem aviso. Nada disso está na documentação da API. Tudo isso aparece na segunda-feira em que o relatório não atualizou.

Neste artigo, comparamos os cinco caminhos possíveis para levar dado de API até o seu BI. O que cada um resolve, onde cada um quebra e as perguntas que decidem a escolha antes de você contratar qualquer coisa.

São estes:

1. Conector nativo do Power BI — o Power Query chamando a API direto.
2. Script próprio — código seu, agendado, gravando num banco.
3. Ferramenta de automação — Zapier, Make, n8n.
4. Ferramenta de código aberto — Airbyte, Meltano, hospedados por você.
5. Plataforma gerenciada — alguém cuida da extração e da carga.

Figura 1 — mapa dos caminhos

Diagrama de uma API à esquerda e um painel à direita, com cinco trilhas ligando os dois, de espessuras diferentes. Cada trilha numerada e nomeada. Serve de mapa para o resto do texto.

Caminho 1 — o conector nativo resolve até a segunda página de resultado

O Power Query tem conector para endereços da web. Você aponta para o endereço, ele traz o dado, você trata no editor. Para um endereço público de cotação ou uma tabela de referência, é a resposta certa. Montar infraestrutura para isso seria exagero.

O problema aparece quando a API devolve o resultado partido em várias páginas. Percorrer página por página vira um laço dentro do Power Query, e esse laço é lento. Autenticação que se renova sozinha também é difícil de manter ali. O gateway de dados vira um ponto de falha que ninguém monitora.

E existe uma perda que quase nunca é percebida a tempo: o histórico. Se a API devolve só o estado atual, o passado não fica em lugar nenhum. Um pedido que passou por três status chega ao seu modelo como uma linha só, sempre a mais recente.

O sintoma é o tempo de atualização subindo toda semana. Quando você percebe, o arquivo do Power BI virou o pipeline de dados da empresa. Ninguém decidiu isso.

Caminho 2 — o script próprio é uma boa decisão até se multiplicar

Um script chama a API, trata o retorno e grava em um banco. Você agenda a execução e funciona. Se alguém do time domina programação, esse caminho é legítimo, flexível e sem custo de licença. Vale registrar isso com clareza, porque boa parte do material publicado por fornecedores omite o ponto.

O que muda é a escala. Um script é gerenciável. Cinco se tornam um sistema — sem aviso de falha, sem repetição automática, sem controle de dependência entre execuções e sem responsável formal.

A pergunta que expõe o custo real é simples: se essa pessoa sair da empresa amanhã, alguém dá manutenção? A resposta costuma ser não. E o conhecimento sai junto com ela.

O problema nunca é o primeiro script. É o décimo quinto.

Caminho 3 — a ferramenta de automação move registro, não gerencia tabela

Zapier, Make e n8n foram construídos para reagir a eventos. Entrou um registro novo, grava uma linha. Nesse cenário são eficazes, e a interface visual reduz a barreira de entrada.

O cálculo muda com o volume. O preço costuma ser cobrado por operação ou por execução. Carregar centenas de milhares de linhas por mês nesse modelo eleva o custo rapidamente, e a carga histórica inicial pode consumir a franquia de um mês inteiro na primeira semana.

Há uma diferença mais relevante que o preço. Essas ferramentas movem registros; elas não gerenciam tabelas. Carga incremental, controle da estrutura das tabelas, reprocessamento de um período e remoção do que sumiu na origem não fazem parte do vocabulário delas.

Automação de processo e integração de dados analíticos parecem equivalentes no diagrama. Não são.

Caminho 4 — código aberto não custa licença, mas custa operação

Airbyte, Meltano e ferramentas do tipo entregam um catálogo grande de conectores e controle total, sem custo de licença. Para quem tem infraestrutura, é uma opção séria.

O peso está no verbo operar. Hospedar por conta própria significa assumir servidor, atualização de versão, monitoramento, cópia de segurança e a correção do conector que parou de funcionar após uma atualização. O software é gratuito. A operação não é.

Para um time de uma ou duas pessoas, isso significa virar administrador de uma plataforma que não era o trabalho de ninguém.

Caminho 5 — a plataforma gerenciada resolve, se a sua origem estiver no catálogo

Nesse modelo, você contrata um serviço responsável pela extração, pela carga e pelo agendamento. Configura origem, destino e frequência; a plataforma resolve autenticação, paginação e carga incremental. É o caminho que transforma integração de dados em rotina, em vez de projeto.

O ponto de ruptura é o catálogo. A maioria dessas plataformas trabalha com uma lista fechada de conectores prontos. Isso resolve Salesforce, HubSpot e Google Analytics. Não resolve o ERP do seu setor, a API interna que seu time construiu, nem o sistema de nicho que a operação usa.

Se a sua origem não está na lista, você depende do planejamento de produto de outra empresa. É o motivo mais comum de uma avaliação terminar em "não atende".

Antes de assinar qualquer plataforma, seis perguntas separam as que servem das que só parecem servir:

• A ferramenta depende de catálogo ou consegue criar o conector sozinha? Algumas leem o arquivo de documentação técnica que a própria API publica, e outras leem a documentação escrita. A pergunta muda de "vocês têm esse conector?" para "essa API está documentada?".
• Quem resolve autenticação e paginação? Credencial que expira, chave que precisa ser renovada, resultado dividido em páginas, campo dentro de campo. Se isso permanece com o seu time, o caminho 5 se tornou o caminho 2 com mensalidade.
• A configuração é validada antes de salvar? Conector que parece pronto e quebra na primeira execução em produção é pior que erro na tela.
• Se há inteligência artificial envolvida, em que ponto ela atua? Criar o conector uma única vez é uma situação: a extração passa a executar sempre da mesma forma, sem variação. Inteligência artificial processando o dado a cada execução é outra. Pergunte de forma direta.
• O que acontece quando a API muda de formato? Campo novo, campo removido, tipo alterado. A ferramenta avisa, ou falha silenciosamente? E se precisar recriar a tabela no destino, pede confirmação antes de apagar o dado existente?
• A cobrança é por linha lida ou gravada? Se cada transformação que grava também consome franquia, sua conta não é o volume da origem. Pergunte se existe teto de fatura e se existe aviso antes de estourar.

Previsibilidade, nesse contexto, não significa preço baixo. Significa ausência de surpresa na fatura.

O trabalho que sobra em todos os caminhos: tudo volta como texto

Escolhido o caminho, ainda sobra uma tarefa que quase nunca entra na conta de esforço.

O que a API devolve tem pouquíssimos tipos de dado. Seu modelo precisa de muito mais. Na prática, o que chega é isto:

Figura 2 — o que chega × o que o modelo precisa

Duas colunas lado a lado. À esquerda, o retorno da API como texto: "1.234,56", "19/08/2026", "S". À direita, o que o modelo dimensional espera: número, data, campo de sim ou não. Entre as duas, uma seta rotulada "alguém precisa fazer isto".

• "1.234,56" — valor monetário como texto, no formato brasileiro. O Power BI interpreta como texto e o cálculo retorna zero.
• "19/08/2026" numa API e "2026-08-19T00:00:00Z" em outra — as duas no mesmo painel.
• "S" e "N" onde você esperava um campo de sim ou não. Ou 1 e 0. Ou a palavra true escrita como texto.
• Campos aninhados — cliente dentro de pedido dentro de lista. É preciso converter essa estrutura em formato tabular.
• Registro inconsistente — e uma decisão a tomar: a carga inteira falha, ou aquele campo é gravado vazio?

Fazer isso no Power Query funciona. Só que prende a regra de negócio dentro do arquivo do Power BI, onde ninguém mais enxerga e ninguém consegue acompanhar as mudanças. O próximo relatório vai refazer tudo de novo.

Na avaliação de qualquer ferramenta paga, esse é o teste mais concreto disponível. Solicite a conversão de R$ 1.234,56 para número e de 19/08/2026 para data, com a opção de gravar vazio quando o valor for inválido, em vez de interromper a execução. Ferramenta construída para o mercado americano trata isso como exceção.

Aqui é o caso comum.

Como decidir entre os cinco caminhos

Quatro perguntas resolvem a maior parte dos casos. A tabela vem depois, para conferência.

1. Quantas origens você vai ter daqui a doze meses? Uma? Script ou conector nativo resolvem. Cinco ou mais? Qualquer solução pontual vira dívida técnica.

2. Você precisa do histórico ou só do estado atual? Muitas APIs devolvem apenas o agora. Se sua análise depende de como o dado mudou, o histórico precisa ser construído na carga. Isso elimina os caminhos 1 e 3 de imediato.

3. Sua origem está no catálogo de alguém? Se suas APIs são as populares, quase tudo serve. Se você depende de sistema de nicho ou de API interna, a ferramenta precisa conseguir gerar o conector a partir da documentação.

4. Quem atende quando a carga falhar às sete da manhã? É a pergunta decisiva e a que mais se evita fazer. Se a resposta for "eu", o custo real da opção gratuita é o seu tempo. E há mais alguém com acesso para verificar? Script instalado na máquina de uma pessoa e ferramenta de usuário único apresentam o mesmo problema durante as férias dessa pessoa.

Respondidas as quatro, a tabela confirma a escolha:

Nos caminhos 4 e 5, guardar o histórico depende de escolher o modo de gravação certo. Sobrescrever é o padrão da maioria das ferramentas — confirme antes de assinar.

Figura 3 — onde cada caminho vive

Gráfico de dispersão. Eixo horizontal: número de origens, de 1 a 10 ou mais. Eixo vertical: volume mensal de linhas. As cinco opções posicionadas como regiões, não como pontos, mostrando onde cada uma deixa de fazer sentido.

Onde o Januss entra

No Januss, a API não precisa estar num catálogo. Você aponta para a documentação técnica que ela publica, ou cola a documentação escrita, e o Januss cria o conector e monta a lista de tabelas disponíveis. Ele descobre sozinho como a API pede autenticação e como ela parte o resultado em páginas.

A configuração não é aceita sem verificação. Antes de salvar, o Januss faz uma chamada real à API e confere se conseguiu ler o dado retornado. Conector com falha não entra no catálogo.

Figura 4 — prova do produto

Captura de tela real da configuração de regras de conversão por coluna, com a lista das treze regras e a escolha entre parar a execução ou gravar nulo. Sem dado de cliente real e sem número de desempenho.

A inteligência artificial escreve esse conector uma única vez. A partir daí a extração executa sempre da mesma forma, sem inteligência artificial no caminho do dado.

O tratamento de formato fica na etapa de carga, não dentro do arquivo do Power BI. São treze regras de conversão que você encadeia por coluna, com oito formatos regionais. R$ 1.234,56 vira número e 19/08/2026 vira data. E você decide, coluna a coluna, o que fazer com o valor que não converte: parar a execução ou gravar vazio.

Nem todo caso se resolve assim. Se a API não possui documentação alguma, não há o que interpretar, e o caminho passa a ser outro. Vale verificar isso antes de iniciar o teste.

Escolher um caminho de integração não tem resposta única. Existe a resposta adequada ao seu volume, ao seu número de origens e ao tamanho do seu time. Quer verificar com a sua própria API? São 14 dias de teste, sem cartão de crédito: criar seu ambiente.