RPA ou integração via API: qual automação escolher

Quase toda empresa tem aquela tarefa: alguém abre o portal do banco, baixa o extrato, copia os valores para uma planilha, confere com o sistema e lança o que falta. Todo dia, do mesmo jeito, com o mesmo risco de digitar um número errado no fim do expediente.

A vontade de automatizar é legítima. O problema é que a primeira ferramenta lembrada costuma ser a mais visível, um robô que repete os cliques da pessoa, e nem sempre é a certa. Automação mal escolhida não elimina o trabalho manual. Troca por outro tipo de trabalho manual: descobrir por que o robô parou.

Este texto compara as três formas mais comuns de automatizar tarefas repetitivas pelo critério que mais pesa em produção: o que acontece quando alguma coisa muda.

Que tipo de tarefa vale automatizar primeiro

Antes de escolher a ferramenta, escolha a tarefa. Nem tudo que é chato merece automação, e automatizar um processo confuso só produz confusão mais rápida.

As boas candidatas têm quatro características:

• Regra clara. Dá para escrever o passo a passo sem "depende" em cada linha. Se quem faz hoje decide com base em experiência, a automação vai precisar de exceções ou de um humano no meio.
• Volume e frequência. O que acontece duas vezes por ano raramente justifica o esforço; o que acontece todo dia, sim.
• Entrada estruturada ou estruturável. Dados que chegam em planilha, arquivo, tela padronizada ou API. Se a entrada é um PDF escaneado ou um e-mail em texto livre, existe uma etapa de extração antes, assunto do nosso texto sobre extração de dados de documentos com IA.
• Erro com custo visível. Lançamento duplicado, nota emitida com dado errado, prazo perdido. Onde o erro custa caro, a automação se paga em confiabilidade, não só em horas economizadas.

RPA: o robô que opera a interface

RPA (Robotic Process Automation) é software que imita um usuário: abre o sistema, clica nos botões, lê o que aparece na tela, digita nos campos. Plataformas como UiPath, Automation Anywhere e Power Automate fazem isso, assim como bibliotecas de automação de navegador como Playwright e Selenium.

A grande vantagem é não depender do outro lado. O robô usa a mesma porta que a pessoa usa. Se o sistema não oferece API, não exporta arquivo e o fornecedor não vai mudar isso, a interface é o único caminho disponível.

É aqui que RPA é a escolha certa:

• Sistema de terceiro sem API, sem exportação e sem perspectiva de ter.
• Portal de órgão público ou de parceiro em que a única forma de consulta é a tela.
• Solução de transição, com data para acabar, enquanto a integração definitiva é construída.
• Volume moderado com regra estável, em telas que raramente mudam.

A desvantagem é que o robô depende de tudo o que ele não controla. O layout da tela, o nome do botão, o tempo de carregamento, o aviso que alguém resolveu colocar num pop-up. O robô não entende a tela: ele reconhece posições, seletores e textos. Mudou um detalhe, ele erra ou para.

E um ponto esquecido: se o portal tem CAPTCHA, isso é um recado. O dono do sistema não quer automação ali. Contornar a barreira costuma violar os termos de uso e cria uma dependência que pode ser bloqueada a qualquer momento. Procure o canal oficial: muitos serviços oferecem webservice para quem se credencia. A NF-e, por exemplo, é transmitida por webservice às Secretarias da Fazenda, com certificado digital ICP-Brasil.

Script e automação de arquivos: o meio-termo esquecido

Entre o robô que clica e a integração completa, existe uma opção que muita empresa pula: trabalhar com os arquivos que os sistemas já produzem.

Quase todo sistema exporta alguma coisa: relatório em CSV, extrato em OFX, arquivo de retorno bancário no padrão CNAB, XML de nota fiscal. Um script que lê esses arquivos, valida, transforma e grava no destino resolve uma quantidade surpreendente de problemas.

As vantagens sobre o RPA são concretas:

• O formato de arquivo muda muito menos que a tela. Outros clientes do fornecedor dependem do mesmo layout, então ele tende a ficar estável.
• Dá para validar tudo antes de gravar. O script confere colunas, tipos e totais. Se o arquivo veio diferente, ele recusa e avisa em vez de gravar lixo.
• Roda em servidor. Não precisa de uma sessão de usuário aberta numa máquina.

A limitação é a latência: arquivo é lote. Se a exportação acontece uma vez por dia, a informação chega com até um dia de atraso. Serve para conciliação e fechamento; não serve para estoque em tempo real.

Outra variação desse meio-termo é ler diretamente o banco de dados de um sistema antigo, em modo somente leitura, ou usar as tabelas de interface que alguns ERPs disponibilizam para importação. Detalhamos esse caminho, e seus cuidados, em como integrar um sistema legado que não tem API.

Integração via API: mais trabalho no início, menos surpresa depois

Uma API é um contrato: o sistema de origem declara quais dados expõe, em que formato e com que autenticação. Quando existe, é quase sempre o melhor caminho.

O esforço inicial é maior. Autenticação, paginação, limites de requisição, códigos de erro e o desenho do que acontece quando a chamada falha. Não é um robô configurado em uma tarde.

Em troca, a integração fica previsível. Uma API versionada não muda porque alguém redesenhou o botão. Mudanças costumam ser anunciadas, com período de convivência entre versões. E o erro volta com um código que diz o que aconteceu.

Uma integração por API bem feita inclui:

• Idempotência. Reenviar a mesma operação não duplica o lançamento. É isso que permite tentar de novo com segurança.
• Retentativa com espera crescente para falhas temporárias, e fila para não perder o que chegou enquanto o destino estava fora.
• Validação na entrada. Dado que não bate com o esperado vai para uma fila de revisão, não para o banco.
• Credencial própria da integração, com permissão mínima, nunca o login de um funcionário.

Se o destino for o ERP, veja o guia sobre como integrar seu sistema com o ERP: TOTVS, SAP, Omie e Bling expõem dados de formas diferentes, e isso muda o desenho inteiro.

Fragilidade: o que quebra quando a tela ou o portal mudam

Esta é a comparação que importa. O esforço de implantação se paga uma vez; a fragilidade se paga todo mês.

Repare no padrão. O RPA não é frágil por ser mal feito. É frágil porque depende de uma camada que foi feita para humanos, e humanos se adaptam a mudanças que um robô nem percebe.

O pior modo de falha nem é o robô parar. É o robô continuar funcionando errado: um campo mudou de posição, ele digita o valor no lugar do vencimento, e ninguém percebe até o fechamento do mês. Parar é barulhento. Errar em silêncio é caro.

Por isso, diante de um robô proposto, pergunte: isso é RPA porque não existe outra porta, ou é uma integração adiada? Se o sistema tem API e ninguém quis investir nela, o robô vira um débito que cobra juros a cada mudança de tela.

Monitoramento e tratamento de falhas em qualquer automação

Qualquer que seja a escolha, automação sem monitoramento é aposta. No processo manual, quando algo dava errado, a pessoa percebia. A automação precisa de algo fazendo esse papel.

O mínimo que toda automação precisa ter:

1. Registro de cada execução. Quando rodou, quanto processou, o que falhou e por quê. Sem isso, "o robô rodou ontem?" não tem resposta.
2. Alerta ativo em falha. Não um log que alguém precisa lembrar de abrir, mas uma notificação para quem é responsável.
3. Alerta de silêncio. Se a automação deveria processar dezenas de itens por dia e processou zero, isso é um incidente, mesmo sem erro registrado.
4. Conferência de totais. Quantidade e soma na origem batem com quantidade e soma no destino? É essa checagem que pega o erro silencioso.
5. Fila de exceções com dono. O que a automação não resolveu vai para uma lista que uma pessoa trata, com prazo. Exceção sem dono vira pendência eterna.
6. Procedimento de retomada. Se a automação parar no meio, dá para rodar de novo sem duplicar? Isso precisa estar decidido antes, não descoberto no dia.

Para ir além do básico, o texto sobre observabilidade com logs, métricas e traces mostra como estruturar essa visibilidade para a operação.

Um cuidado adicional: automações costumam manipular dados pessoais, como CPF e dados bancários. A LGPD (Lei 13.709/2018) vale para o robô como para qualquer sistema: logs sem dado pessoal desnecessário e credenciais protegidas, com uso rastreável.

Os erros que mais aparecem

Robô rodando no computador de um funcionário, com o login dele. Quando a pessoa sai de férias, troca a senha ou desliga a máquina, a automação para. E a trilha de auditoria passa a registrar como dela ações que ela não fez.

RPA "temporário" sem data para acabar. A transição vira permanente, e a integração definitiva nunca sai do papel porque "já está funcionando".

Automatizar sem questionar o processo. Às vezes a tarefa só existe para corrigir um problema anterior, como um cadastro duplicado. Automatizar a correção perpetua a causa.

Como medir se a automação deu certo

"Economizou horas" é o indicador mais citado e o menos confiável, porque ignora o tempo gasto corrigindo o que a automação fez errado. Meça também:

• Execuções sem intervenção humana. A automação que precisa de alguém toda semana não está automatizando.
• Tamanho da fila de exceções. Deveria cair conforme as regras amadurecem.
• Tempo entre a falha e a detecção. Se um erro leva dias para ser percebido, o monitoramento falhou.
• Esforço de manutenção. Quantas vezes a automação precisou de ajuste. É aqui que o RPA frágil aparece.
• Erros que chegaram ao cliente ou ao fechamento. O número que realmente importa.

Uma matriz de decisão para o seu caso

Responda às perguntas na ordem. A primeira resposta afirmativa indica o caminho.

E um roteiro curto para colocar em prática:

1. Liste as tarefas candidatas e dê nota para volume, clareza da regra e custo do erro.
2. Mapeie cada sistema envolvido: tem API? Exporta o quê? Quem é o fornecedor?
3. Documente o processo como ele é de verdade, com as exceções, sentado ao lado de quem faz hoje.
4. Escolha o mecanismo pela matriz, não pela ferramenta que já está disponível.
5. Defina o monitoramento antes de construir: o que é sucesso, o que é falha, quem recebe o alerta.
6. Comece por uma tarefa, rode em paralelo com o processo manual por um período e compare os resultados.
7. Só desligue o manual quando a conferência de totais bater de forma consistente.

O passo mais pulado é o sexto. Rodar em paralelo parece desperdício, mas é o único jeito de descobrir as exceções que ninguém lembrou de contar.

Como a Pervian Tech trabalha esse tipo de automação

Começamos por um diagnóstico do processo e dos sistemas envolvidos: o que existe de API, de exportação e de acesso a dados, e onde a automação pode falhar. Só então recomendamos o mecanismo, que muitas vezes combina mais de um, como um script sobre arquivo agora e uma API quando o fornecedor disponibilizar.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de entender o contexto, o volume e o que já está em uso. O cronograma segue fases (diagnóstico, protótipo, primeira automação em produção, evolução) e é fechado após o diagnóstico. Esse trabalho faz parte da nossa atuação em arquitetura de software.

Se existe uma tarefa repetitiva consumindo a sua equipe, conte o cenário para a gente.