Índice do artigofaltam 10 min de leitura
Na maioria das vezes, "o ERP não tem API" descreve uma pergunta que ainda não foi feita, não um sistema.
A frase chega pronta do fornecedor, geralmente por e-mail, geralmente com duas linhas. Ela encerra reunião, adia projeto e faz empresa trocar de ERP sem precisar. Este artigo faz duas coisas: separa os quatro significados possíveis dessa frase, e, para o caso em que a ausência é real, coloca preço nas cinco saídas que restam.
Resumo do artigo
- A frase "não tem API" costuma significar módulo não contratado, serviço desligado no ambiente, campo não publicado ou integração vendida à parte. Só o último caso é uma decisão comercial do fornecedor.
- Quando a API realmente não existe, sobram cinco saídas: arquivo em pasta, banco espelho, RPA, camada intermediária e plataforma de integração.
- Só uma delas tem preço público por unidade. A Microsoft cobra US$ 150 por bot ao mês pelo Power Automate Process, e US$ 215 quando a máquina é hospedada por ela.
- A escolha é de operação e de contrato, não de tecnologia: o que decide é o atraso tolerado, o volume e quem responde quando a integração para.
"Não tem API" quase nunca significa que não existe API
A frase tem quatro leituras, e elas exigem ações completamente diferentes. Três delas se resolvem dentro do ERP que a empresa já tem.
- Módulo não contratadoA API existe no produto e não está no contrato da empresa. Vira negociação comercial, não projeto técnico.
- Serviço desligado no ambienteO framework publica a interface e ninguém habilitou naquele servidor. É configuração, e costuma sair em dias.
- Campo não publicadoA API responde e o dado que você precisa não vem nela. Exige alteração do lado do fornecedor, e entra no calendário dele.
- Integração vendida à parteO fornecedor tem o componente e prefere vender o projeto de integração. É a resposta comercial disfarçada de limitação técnica.
A quinta possibilidade, a ausência real, existe e é mais rara do que parece. Ela aparece em sistema antigo, em software feito sob medida por alguém que saiu, e em produto de nicho que nunca foi pensado para conversar com nada. Esse é o caso que o resto do artigo trata.
No TOTVS Protheus, por exemplo, "ter API" já são três perguntas separadas, e a resposta muda conforme o ambiente. O mesmo raciocínio vale para praticamente qualquer ERP de mercado.
As quatro perguntas que separam "não existe" de "não está ligado"
Mande as quatro por escrito, na mesma mensagem, antes de aceitar a resposta. Exigir a resposta por escrito é o que transforma opinião em compromisso, e é o que você vai levar para a reunião de contrato depois.
- O produto publica alguma interface de integração? Peça o nome dela e o link da documentação, não um sim ou não. Documentação pública é o que permite orçar sem depender de reunião.
- Essa interface está habilitada no nosso ambiente? Serviço disponível no produto e serviço ligado no servidor da empresa são coisas diferentes, e a segunda é configuração.
- Os campos que precisamos estão expostos no recurso publicado? Liste os campos pelo nome que aparece na tela do ERP. Campo preenchido na tela não significa campo devolvido na resposta.
- O que falta é contrato ou é desenvolvimento? Se for contrato, peça a proposta. Se for desenvolvimento do fornecedor, peça o prazo e a fila. As duas respostas são aceitáveis; a ausência delas não é.
Se as quatro respostas confirmarem que não há caminho publicado, aí sim o projeto muda de forma. Começa a escolha entre cinco saídas, e cada uma cobra em um lugar diferente.
As cinco saídas não são alternativas equivalentes. Duas delas movem dado em lote e aceitam atraso. Uma repete cliques de pessoa. Uma constrói o que o ERP não publicou. E uma terceiriza a conexão inteira, cobrando por evento.
Na prática, projetos reais combinam duas: lote para o volume histórico e uma segunda saída para o que precisa ser recente.
Arquivo em pasta: a saída mais barata, e o atraso que ela cobra
Arquivo é a saída que entra em produção mais rápido e a que menos depende do fornecedor. Quase todo ERP exporta CSV, TXT posicional ou XML, nem que seja por relatório agendado, e quase todo ERP importa o mesmo formato de volta. A empresa combina uma pasta, um horário e um layout, e a integração existe sem nenhuma linha de código dentro do ERP.
O preço vem em forma de atraso. O dado é sempre o da última exportação, e a operação passa a conviver com uma janela: o pedido que entrou às 10h aparece no outro sistema no ciclo das 14h. Isso é aceitável para catálogo, folha, fechamento contábil e carga de histórico. Não é aceitável para saldo de estoque em loja virtual com venda concorrente, porque o cliente compra o que não existe.
A troca por arquivo funciona enquanto o layout for o combinado. O dia em que alguém acrescenta uma coluna no relatório do ERP, o importador do outro lado recebe um arquivo que não reconhece.
Quando a quebra não é alarmada, ela aparece semanas depois, no fechamento, como divergência de número sem causa aparente.
O segundo custo é silencioso e aparece meses depois: layout de arquivo não tem contrato. Alguém acrescenta uma coluna no relatório do ERP, o importador quebra, e ninguém descobre até o fechamento do mês. Se a saída escolhida for essa, o mínimo é versionar o layout, validar a quantidade de colunas na entrada e alarmar quando o arquivo do dia não chegar.
Banco espelho: dá para ler, e é aí que o suporte termina
A leitura direta no banco resolve consulta e relatório, e não resolve escrita. A distinção é a coisa mais importante desta seção. Ler uma cópia do banco do ERP é um caminho defensável em sistema legado sem quem o mantenha; escrever na base do ERP contorna a validação da aplicação e costuma ser vedado pelo contrato de suporte do fornecedor. No SAP Business One, por exemplo, o banco ser SQL Server não autoriza escrever nele, e a escrita suportada passa pela DI API ou pelo Service Layer.
A palavra "espelho" também é importante. Apontar relatório para o banco de produção transforma uma consulta mal escrita em lentidão para quem está faturando. O desenho que funciona é uma réplica de leitura, atualizada em intervalo combinado, com acesso somente de leitura e com as consultas rodando longe da base que a operação usa.
Prós
- Chega em todo dado que existe, inclusive o que nenhuma API publicaria
- Não depende do calendário nem do orçamento do fornecedor do ERP
- Custo de implantação baixo quando a réplica já existe para backup
Contras
- Resolve leitura e não resolve escrita, que continua dependendo da aplicação
- Quebra em silêncio a cada atualização de versão que muda a estrutura das tabelas
- Pode conflitar com a cláusula de suporte do contrato, e isso se confere antes, não depois
O que esse quadro decide: banco espelho é excelente para tirar relatório, alimentar painel e abastecer um assistente de busca interna, e é a saída errada para lançar documento.
RPA: o robô custa US$ 150 por bot por mês e quebra quando a tela muda
RPA é a única saída que não precisa de nenhuma cooperação do ERP, e é também a que tem o preço unitário mais visível. O robô faz o que uma pessoa faria: abre a tela, preenche o campo, clica em confirmar. Para o ERP, é um usuário. Isso resolve exatamente o caso em que nada mais funciona, porque a interface gráfica sempre existe.
Power Automate Premium
Robô atendido, com pessoa na máquina US$ 15por usuário, ao mês, pago anualmente- Desktop flows atendidos
Power Automate Process
Referência de custo Robô não atendido, rodando sozinho US$ 150por bot, ao mês, pago anualmente- Desktop flows não atendidos
Power Automate Hosted Process
Robô não atendido em máquina da Microsoft US$ 215por bot, ao mês, pago anualmente- Máquina virtual hospedada incluída
Fonte: página de preços do Power Automate, Microsoft, lida em 21/09/2026. A própria página registra que os valores são de referência e variam por região e por acordo.
Três leituras saem desses números. A primeira: automação não atendida, que é a que serve para integração, custa dez vezes o robô atendido, porque a licença deixa de ser de pessoa e passa a ser de processo rodando sozinho. A segunda: a linha hospedada cobra US$ 65 a mais por bot para você não manter a m áquina, o que costuma ser barato perto do custo de administrar um parque de estações. A terceira, que é a que decide: o preço do robô é o menor dos custos.
O custo maior do RPA é a manutenção. O robô se apoia na tela, então ele quebra quando o fornecedor muda o layout, quando a versão do ERP altera a ordem dos campos, quando aparece um aviso novo no meio do fluxo. Cada uma dessas quebras é um incidente de operação, não um bug de software, e chega sem aviso. RPA é uma saída legítima quando o volume é baixo, o fluxo é estável e o prazo é curto. É uma saída cara quando vira a arquitetura permanente da empresa.
Camada intermediária: construir a API que o ERP não publicou
A camada intermediária vale quando mais de um sistema vai precisar do mesmo dado. Em vez de cada consumidor inventar seu próprio jeito de chegar no ERP, um componente só conversa com o legado, e todo o resto conversa com esse componente por uma interface moderna e documentada.
O ganho comercial é concreto e tem nome: o dia em que a empresa trocar de ERP, quem muda é a camada, não os três consumidores. Isso reduz o custo da troca e encurta o prazo dela. Vale dizer o que a camada não faz, porque a insinuação contrária é comum: desenho de arquitetura reduz, mede e barateia a dependência de um fornecedor. Ele não garante independência, que é assunto de contrato.
O custo é um componente novo para manter, com fila, repetição de envio e monitoramento próprios. Se a empresa tem um consumidor só e nenhuma previsão de segundo, a camada é overhead e o certo é ir direto.
Plataforma de integração: barata no piloto, cara no volume
A plataforma de integração cobra por evento, e é por isso que ela engana no piloto. A conta de entrada é minúscula e a curva é reta: no plano Core do Make, US$ 9 por mês compram 10.000 créditos, o que dá cerca de US$ 0,0009 por crédito. Multiplicar isso pelo volume real da operação é um exercício de dois minutos que muda a decisão.
Há um segundo limite que quase ninguém orça, e ele não é de preço: é de quota do outro lado. Quando o alvo é um ERP de nuvem brasileiro, a API dele tem teto próprio. O Bling publica 3 requisições por segundo e 120.000 por dia. O Omie publica 960 requisições por minuto por endereço IP, 240 por minuto na mesma combinação de IP, chave e método, 100 registros por página, e devolve HTTP 425 com bloqueio de 30 minutos depois de dez requisições com erro seguidas. Uma sincronização ingênua bate nesses limites antes de bater no orçamento, e o sintoma no negócio é o pedido que não subiu.
A saída que quase ninguém propõe: comprar o módulo do próprio fornecedor
Antes de construir qualquer uma das quatro saídas anteriores, peça a proposta de integração do fornecedor do ERP e compare. A resposta "não tem API" às vezes é a forma curta de "tem, e é um item comercial que você não contratou".
Essa comparação costuma ser desconfortável e quase sempre vale a pena, por um motivo que não é preço: quando a integração é do fornecedor, a responsabilidade pela quebra na próxima atualização é dele. Nas outras quatro saídas, a responsabilidade é da empresa ou do parceiro que a construiu. Não existe tabela pública de preço desses módulos no mercado brasileiro, então a única forma de saber é pedir a proposta por escrito, com o escopo dos campos e a cláusula de manutenção.
Quando a proposta do fornecedor chega cara demais, ela continua sendo útil: vira o teto de referência para orçar as outras saídas.
Como escolher, e o que isso muda no contrato
A escolha não é técnica. Ela sai de três perguntas de operação: qual atraso a operação tolera, qual o volume por mês e quem atende o telefone quando parar às 23h de uma sexta.
| Saída | Atraso típico | Onde o custo cresce | O que colocar em contrato |
|---|---|---|---|
| Arquivo em pasta | Horas | Correção de layout quebrado, sempre no fechamento | Layout versionado e alarme quando o arquivo do dia não chegar |
| Banco espelho | Minutos | Cada atualização de versão do ERP | Acesso somente de leitura e confirmação de que o suporte permite |
| RPA | Minutos | Licença por bot mais manutenção a cada mudança de tela | Quem refaz o robô quando o ERP muda, e em quanto tempo |
| Camada intermediária | Segundos a minutos | Construção inicial e manutenção do componente | Propriedade do código, acesso ao repositório e plano de saída |
| Plataforma de integração | Segundos | Preço por evento e quota da API do outro lado | Teto de consumo mensal e o que acontece ao estourar |
A camada intermediária é a que sustenta mais consumidores ao longo do tempo, e não é a resposta certa para todo mundo: com um consumidor só e prazo curto, arquivo em pasta entrega antes e custa menos. A regra prática que fecha o assunto é que a saída escolhida precisa aparecer no contrato com nome, responsável e prazo de correção. Integração sem dono é a que some do orçamento e reaparece como parada de operação.
Seu ERP não publica o que você precisa?
Avaliamos o que o seu sistema expõe hoje e qual saída cabe no seu volume e no seu prazo.
Perguntas frequentes
Quase nunca. Antes de aceitar a resposta, confirme por escrito se o módulo de integração foi contratado, se o serviço está ligado naquele ambiente e se o campo que você precisa está publicado. As três perguntas costumam mudar a resposta.
Tecnicamente quase sempre dá, e é aí que o risco mora. Ler uma cópia é um caminho defensável; escrever na base do ERP contorna a validação do sistema e costuma ser vedado pelo contrato de suporte do fornecedor. Confira o contrato antes.
Resolve o fluxo, não o dado. O robô repete o que uma pessoa faria na tela, então ele quebra quando a tela, a versão ou o layout mudam. A Microsoft cobra US$ 150 por bot ao mês pelo Power Automate Process, com desktop flows não atendidos, em preço de tabela de setembro de 2026.
Quando mais de um consumidor vai precisar do mesmo dado e a operação não pode esperar o calendário do fornecedor. A camada concentra a regra num lugar só e deixa o legado intacto, ao custo de um componente novo para manter.
No piloto, quase sempre. No volume, o preço é por operação. No plano Core do Make, US$ 9 por mês compram 10.000 créditos, o que dá menos de um centavo de dólar por crédito, e a conta cresce em linha reta com o número de eventos.
Arquivo em pasta, se o atraso de algumas horas for aceitável na operação. É a saída que entra em produção mais rápido e a que menos depende do fornecedor do ERP.
Fontes e método
Apuração em 21/09/2026. Preços e limites de terceiros foram lidos nas páginas oficiais dos fornecedores na mesma data: a página de preços do Power Automate, da Microsoft; a página de planos do Make; a documentação de limites da API v3 do Bling; e o artigo de limites de consumo da API do Omie. Preço de tabela muda, e a própria Microsoft registra que os valores dela variam por região e por acordo.
Os fatos de arquitetura de SAP Business One e TOTVS Protheus vêm das apurações que já publicamos sobre cada um, com as fontes dos fornecedores citadas lá. O artigo não afirma qual proporção dos ERPs do mercado brasileiro publica API, nem preço de módulo de integração de ERP nacional, porque nenhum levantamento público sustenta os dois números.
