Leonardo Peron5 min de leitura
"Esse sistema não tem API" é uma das frases mais repetidas em reunião de integração no Brasil, e uma das menos verificadas. Ela costuma significar outra coisa: o comercial do fornecedor não soube responder, ou a API existe e é um módulo pago, ou existe e só é liberada para parceiro homologado. Antes de desenhar contorno, vale gastar uma semana atrás da resposta real.
Confirme a ausência antes de aceitá-la
Pergunte por escrito, ao suporte técnico e não ao vendedor, quatro coisas específicas — porque "vocês têm integração?" convida a uma resposta vaga:
Existe API documentada, e sob quais condições comerciais. Existe exportação agendada, para pasta ou servidor de transferência. Existe conector oficial para ferramenta de BI ou de integração — onde ele existe há um caminho de leitura para reaproveitar. E existe programa de parceiro, com documentação que não circula fora dele.
A resposta muda o projeto inteiro e merece estar num e-mail, não numa lembrança de call. Sem ela, o resto deste texto é escolha entre saídas piores.
Primeira saída: exportação agendada
É a menos glamourosa e quase sempre a melhor. O sistema grava um arquivo com o que mudou, num horário combinado, e o outro lado lê.
O motivo de ela ganhar não é técnico, é contratual: arquivo tem layout, e layout é um acordo que alguém escreveu. Tabela de banco não é acordo nenhum, e tela muito menos. Publicando o layout, o fornecedor assume que aquilo tem versão e que mudança se avisa — mais do que as outras duas saídas oferecem.
O custo aparece em três lugares: a latência é o intervalo entre as rodadas, o lado que grava não sabe se alguém leu, e o conteúdo é o que o fornecedor decidiu exportar, não o que você precisa. Os detalhes de como fazer isso sobreviver estão em integração por arquivo, que é o formato mais antigo em uso e o menos escrito.
Segunda saída: ler o banco direto
É a mais tentadora: o dado está ali, sem cota e sem espera, e num fim de semana alguém entrega uma consulta que parece resolver o problema.
O que se compra junto raramente é discutido. O banco de um sistema é a implementação dele, não um contrato: ninguém prometeu que a tabela continua existindo nem que a coluna continua significando a mesma coisa depois da próxima versão. Quando muda, não vem erro — vem dado errado, que é a falha mais cara de todas. É o mesmo alerta que vale para integração de ERP, e ele não fica mais barato porque o sistema é pequeno.
Há ainda dois efeitos que só aparecem depois. A consulta pesada disputa recurso com a operação, e a lentidão da terça vira discussão sem dono. E há contrato em que acesso direto ao banco suspende o suporte: no dia do problema, a resposta é que a base foi tocada por fora.
O que exigir por contrato antes de aceitar essa via, e antes de escrever a primeira consulta:
- Autorização escrita do fornecedor, dizendo que o acesso não afeta suporte nem garantia.
- Somente leitura, e não como promessa — como usuário sem permissão de escrita. Escrever na tabela pula a regra que o sistema aplica ao gravar, e o defeito aparece meses depois, num fechamento.
- Réplica ou janela de baixa carga, para a consulta não competir com quem está operando.
- Uma camada de visões estáveis mantida pelo fornecedor, em vez de tabela crua. É o único item que transforma implementação em contrato.
- Aviso de mudança de esquema junto com o comunicado de nova versão, e uma pessoa nomeada que manda esse aviso.
- Um plano de reteste a cada atualização do sistema, tratado como risco e não como formalidade.
Quando o fornecedor recusa todos, a informação é sobre o fornecedor, não sobre o banco — e ela vale para a decisão de integrar ou trocar.
Terceira saída: automação de tela
O robô abre o sistema, digita e lê como uma pessoa faria. É a única saída que funciona quando não há arquivo nem banco — portal de órgão público, sistema de terceiro, legado sem interface —, e a comparação entre RPA e integração por API detalha quando ela se justifica.
O que falta no orçamento não é a construção, é a operação. O robô precisa de uma credencial, e credencial é de uma pessoa: quando ela sai, ou quando entra segundo fator, o robô para. As ações ficam registradas com o nome dessa pessoa, o que atrapalha auditoria. E mudança de tela quebra tudo — em silêncio, que é o pior jeito de quebrar.
Automação de tela é ponte, e ponte precisa de data de demolição. Sem previsão de saída, ela vira infraestrutura crítica que ninguém projetou para isso — o mesmo lugar em que mora o sistema que ninguém sabe manter.
O levantamento que decide a via
Antes de escolher, junte estas respostas e leve-as ao levantamento:
- A resposta escrita do fornecedor às quatro perguntas do começo.
- Quais entidades precisam atravessar, e em que direção — se alguma precisa escrever no sistema sem API, isso elimina a leitura de banco e restringe muito o resto.
- Qual atraso é aceitável em cada uma. Exportação diária resolve cadastro e não resolve saldo.
- Com que frequência o sistema é atualizado, e se o fornecedor avisa antes.
- Quem é o dono da credencial que a via escolhida vai usar, e o que acontece quando essa pessoa sai.
O teste que vale mais que os cinco: peça ao fornecedor o registro de mudanças da última atualização. Se ele existir e disser o que mudou no banco ou no layout, qualquer via fica viável. Se não existir, você já sabe o formato do custo de manter — e ele entra na conta agora, não depois.