Resposta curta
Use API sempre que existir: é mais rápida, mais confiável e não quebra quando a tela muda. RPA se justifica quando o sistema não expõe API e não há outro caminho — sistema legado sem interface, portal de terceiro, órgão público. Nesse caso, trate o robô como solução temporária, com monitoramento.
Quando integração por api ganha
- O sistema expõe API, webhook ou exportação de arquivo
- O volume é alto e o dado precisa chegar rápido
- A operação não pode depender de uma tela continuar igual
- Existe necessidade de reprocessar sem duplicar
O custo escondido é o levantamento: descobrir o que a API realmente entrega, qual a cota e o que ela não expõe leva tempo antes da primeira linha de código. Em compensação, o resultado sobrevive a mudança de layout.
Quando rpa (automação pela tela) ganha
- O sistema não tem API nem exportação — legado, portal de terceiro, órgão público
- O processo é estável e a tela não muda com frequência
- O volume é moderado e o atraso é aceitável
- É solução temporária enquanto a integração de verdade não vem
O custo escondido é a fragilidade: o robô quebra quando a tela muda, e quebra em silêncio. Sem monitoramento, a operação descobre dias depois. RPA sem plano de substituição vira dívida permanente.
Lado a lado
| Critério | Integração por API | RPA (automação pela tela) |
|---|---|---|
| Depende do sistema expor API | Sim | Não |
| Velocidade | Segundos | Minutos por transação |
| Volume suportado | Alto | Limitado pela tela |
| Quebra quando o layout muda | Não | Sim, e em silêncio |
| Reprocessamento seguro | Sim, com idempotência | Difícil e arriscado |
| Custo de manutenção | Baixo, muda com a API | Alto, muda com a tela |
| Tempo até funcionar | 2 a 5 semanas | 1 a 3 semanas |
As perguntas que decidem
O sistema expõe alguma forma de acesso a dado?
API, webhook, exportação agendada, até leitura de banco. Se houver qualquer uma delas, ela ganha do robô — inclusive a mais precária, porque não depende de a tela continuar igual.
Com que frequência a tela muda?
Sistema de terceiro que atualiza sozinho quebra o robô sem aviso. Se a interface muda a cada trimestre, o custo de manutenção do RPA supera o de esperar por uma integração de verdade.
O que acontece se o robô parar por dois dias?
Se a resposta for 'nada grave', RPA serve. Se a operação para, o robô virou infraestrutura crítica sem ter sido projetado para isso — e aí ele precisa de monitoramento, plantão e plano de substituição.
Existe prazo para trocar aquele sistema?
Se o legado sai em um ano, o RPA como ponte é uma decisão excelente. Se não há previsão, ele vai ficar — e aí vale investir na integração real desde o começo.
Perguntas frequentes
RPA é sempre gambiarra?
Não. É a ferramenta certa quando não existe outro caminho, e há casos legítimos: portal de órgão público sem API, sistema legado sem interface, fornecedor que não abre acesso. O erro é usar RPA por conveniência quando existe API — aí vira dívida escolhida.
Dá para começar com RPA e migrar para API depois?
Dá, e é um bom desenho quando a integração real depende de terceiro. O cuidado é isolar a camada: se o resto do fluxo não sabe se o dado veio de robô ou de API, a troca depois é localizada em vez de ser um novo projeto.
E a IA que 'usa o computador'? Substitui RPA?
Ainda não para processo crítico em volume. Ela lida melhor com variação de tela que o robô tradicional, e erra de formas menos previsíveis. Hoje usamos onde o erro é barato e há revisão; onde a consequência é financeira, o desenho continua sendo API com regra determinística.
Como monitorar um robô?
Registro de cada execução, alerta quando falha ou quando o tempo foge do normal, e conferência do resultado contra o esperado. Robô sem monitoramento não é automação: é uma aposta de que ninguém mexeu na tela.