Entenda como a governança de APIs evita desperdícios, protege dados de clientes e reduz riscos de segurança e compliance no negócio digital.
No episódio da Guru Talks, André Cruz, CEO e cofundador da Digital Manager Guru, apresentou um caso real que evidenciou os riscos desse cenário: mais de meio milhão de chamadas a uma API em apenas sete dias, com aproximadamente 75% das requisições identificadas como desnecessárias.
O problema foi além do desperdício de recursos tecnológicos. Credenciais sem controlo, servidores desconhecidos, dados de clientes expostos e automações sem responsáveis definidos representaram riscos significativos para a continuidade e a segurança das operações.
A principal conclusão foi clara: a automação só se tornou uma vantagem competitiva sustentável quando foi acompanhada por governança, segurança e eficiência arquitetural.
[00:34] A facilidade de conectar ferramentas contrastou com a dificuldade de controlar as integrações em funcionamento.
A governança de APIs correspondeu ao conjunto de práticas, políticas e controlos utilizados para gerir as interfaces de comunicação entre sistemas, incluindo acessos, credenciais, fluxos de dados, monitorização, documentação e responsabilidades.
No contexto dos negócios digitais, essa governança tornou-se particularmente importante porque as operações passaram a depender de múltiplas plataformas, como sistemas de pagamento, CRM, ferramentas de automação, plataformas de vendas e serviços de análise de dados.
André Cruz destacou que a criação de integrações se tornou consideravelmente mais acessível com ferramentas low-code, plataformas de automação e inteligência artificial. Um profissional conseguiu construir um fluxo funcional em poucos minutos, mas isso não significou que a integração estivesse preparada para operar com segurança e eficiência em escala.
[01:06] O desafio passou da criação de automações para a sua gestão e manutenção.
Uma integração poderia funcionar corretamente durante os primeiros testes e, ainda assim, apresentar problemas quando fosse submetida a grandes volumes de dados, alterações de estado, falhas de comunicação ou mudanças na equipa responsável.
Entre os problemas que a ausência de governança poderia provocar, destacaram-se:
A governança permitiu que a empresa passasse a conhecer o funcionamento das integrações, os responsáveis por cada processo e os destinos das informações partilhadas.
[05:22] — André Cruz distinguiu a execução técnica da responsabilidade de quem aprovava e supervisionava o trabalho.
O problema não esteve apenas na qualidade do código. A liderança também teve responsabilidade ao aceitar integrações sem documentação, validação arquitetural ou mecanismos de monitorização.
Quando a gestão avaliou exclusivamente se uma solução funcionava, deixou de considerar questões importantes para a operação:
A maturidade tecnológica dependeu tanto da qualidade da implementação como da capacidade da empresa para supervisionar o que foi construído.
[02:39] O caso apresentado por André Cruz demonstrou como uma integração ineficiente poderia gerar desperdício em grande escala.
Durante uma análise realizada ao longo de sete dias, a equipa de engenharia da Digital Manager Guru identificou um volume superior a 500 mil chamadas à API de um cliente.
Segundo o relato, aproximadamente 70 mil chamadas eram realizadas por dia, distribuídas por mais de uma dúzia de utilizadores de API. Cerca de 75% das requisições foram classificadas como redundantes, desnecessárias ou resultantes de erros de lógica.
O caso envolveu uma empresa com faturação anual superior a 200 milhões, segundo André Cruz. O apresentador também referiu que problemas semelhantes tinham sido identificados noutras operações.
Os números ilustraram uma questão importante: uma integração tecnicamente funcional poderia continuar a ser operacionalmente ineficiente.
[13:52] O excesso de requisições afetou o consumo de recursos e a estabilidade operacional.
Cada chamada desnecessária poderia representar consumo de processamento, largura de banda, tempo de execução e capacidade dos serviços envolvidos.
Quando esse comportamento se repetiu milhares de vezes por dia, o custo acumulado tornou-se mais significativo.
Entre as principais consequências identificadas estiveram:
Para um negócio digital com grande volume de vendas, subscrições ou transações, esses problemas poderiam comprometer processos críticos, sobretudo durante campanhas comerciais e períodos de elevada procura.
[28:11] André Cruz relacionou as falhas de arquitetura com riscos que poderiam surgir nos momentos de maior exigência operacional.
O débito técnico acumulou-se quando decisões de implementação privilegiaram a rapidez inicial, sem considerar adequadamente a manutenção, a escalabilidade e a recuperação de falhas.
Uma rotina que funcionava num ambiente de testes poderia apresentar limitações quando passasse a processar centenas de milhares de registos.
O problema tornou-se ainda mais crítico quando a empresa não tinha documentação suficiente para compreender o fluxo ou corrigir os seus defeitos sem interromper outras operações.
Por isso, o custo de uma integração não deveria ser avaliado apenas pelo tempo necessário para a desenvolver. Também deveria incluir os recursos consumidos durante a execução, a manutenção futura e o risco de interrupção do negócio.
[06:20] O episódio apresentou exemplos concretos de rotinas que continuavam a consultar e a descarregar informação sem necessidade.
Esses exemplos mostraram como pequenas decisões de arquitetura poderiam gerar desperdício quando fossem repetidas diariamente e aplicadas a grandes bases de dados.
[06:29] Uma rotina consultava repetidamente o histórico de vendas desde janeiro do ano anterior.
O processo voltava a descarregar dados antigos que não tinham sofrido alterações. Embora a rotina pudesse garantir a disponibilidade dos registos, o seu funcionamento implicava trabalho repetido sem benefício proporcional.
Uma abordagem incremental teria permitido consultar apenas os dados novos ou alterados desde a última sincronização.
Dessa forma, o sistema teria reduzido o volume de informação processada e o número de chamadas realizadas.
[06:49] Outro exemplo envolveu uma rotina que dedicava mais de cinco horas por dia a percorrer quase meio milhão de assinaturas sem alterações de estado.
O processo consumia recursos para confirmar repetidamente uma informação que permanecia igual.
Para operações com subscrições, a sincronização deveria ter considerado as alterações efetivas, como mudanças de estado, cancelamentos, aprovações ou atualizações relevantes.
A consulta integral e frequente de todos os registos não representava, por si só, uma garantia superior de qualidade dos dados.
[07:14] O caso descrito incluiu uma rotina que voltava a descarregar cerca de 550 mil contactos diariamente, embora apenas aproximadamente 30 fossem novos.
A diferença entre o volume total e a quantidade de informação nova demonstrou a ineficiência do processo.
Em vez de voltar a transferir toda a base, a integração poderia ter utilizado identificadores únicos, datas de criação ou mecanismos de sincronização incremental.
O resultado esperado seria uma redução do tráfego, do tempo de processamento e da carga sobre os sistemas envolvidos.
[07:43] O episódio também apresentou um sistema que consultava uma API a cada 60 segundos para verificar se existia uma nova campanha, embora a equipa responsável atualizasse o registo apenas uma vez por semana.
A frequência das consultas não estava alinhada com a frequência real das alterações.
Uma estratégia de sincronização eficiente deveria ter considerado a natureza dos dados, a periodicidade das atualizações e a importância de receber informação em tempo útil.
A frequência de consulta deveria ter sido determinada pela necessidade operacional, e não por uma rotina automática sem contexto.
[08:17] André Cruz interpretou os exemplos como sinais de falta de contexto sobre o funcionamento dos sistemas.
Em muitos casos, a repetição das consultas surgiu como uma tentativa de evitar a perda de informação. Contudo, a ausência de uma estratégia clara de sincronização acabou por aumentar o desperdício e a complexidade.
O problema foi agravado quando as equipas se concentraram exclusivamente em fazer o fluxo funcionar, sem avaliar se a solução continuaria a ser eficiente quando aplicada a grandes volumes de dados.
O episódio reforçou, assim, a importância de rever a arquitetura antes de aceitar uma integração como concluída.
[09:23] André Cruz apresentou os webhooks como uma alternativa mais eficiente às consultas repetidas quando o objetivo era detetar alterações nos sistemas.
O polling consiste em consultar periodicamente uma API para verificar se determinado dado foi alterado. Um webhook, por sua vez, permite que um sistema envie uma notificação quando ocorre um evento relevante, como uma venda aprovada, uma assinatura alterada ou um pagamento atualizado.
A principal diferença esteve na forma como a informação foi obtida: através de consultas repetidas ou de notificações desencadeadas por acontecimentos.
No modelo de polling, a aplicação realizou consultas à API segundo uma frequência previamente definida.
Por exemplo, um sistema poderia consultar uma plataforma de vendas a cada minuto para verificar se existiam novas transações.
Se nenhuma alteração tivesse ocorrido, a consulta consumiria recursos sem produzir informação nova. Quando esse comportamento se repetisse em vários sistemas, o volume de requisições poderia aumentar significativamente.
O polling continuou a ser útil em determinadas situações, nomeadamente quando não existia suporte para notificações ou quando era necessário executar uma reconciliação periódica dos dados.
O problema identificado no episódio foi a utilização indiscriminada dessa abordagem, mesmo quando existiam mecanismos mais adequados.
[09:42] A Digital Manager Guru utilizou webhooks para comunicar alterações em objetos relevantes para os sistemas integrados.
Quando ocorria um evento, a plataforma enviava uma notificação ao sistema externo, permitindo desencadear o processamento necessário sem obrigar a aplicação a consultar continuamente a API.
Entre os exemplos mencionados no episódio estiveram:
Esta abordagem permitiu reduzir consultas desnecessárias e tornar a comunicação entre sistemas mais orientada a eventos.
[30:15] André Cruz apresentou uma regra prática: utilizar o webhook para detetar a alteração e consultar a API quando fosse necessário obter informação adicional ou validar os dados.
A estratégia descrita pela Digital Manager Guru não consistiu em confiar cegamente em todas as informações recebidas por webhook.
No caso apresentado, a notificação funcionava como um sinal de que determinado objeto tinha sido alterado. A aplicação consultava depois a API do sistema de origem para obter a versão atualizada dos dados.
Esta distinção foi particularmente importante em processos financeiros, nos quais a integridade da informação precisava de ser preservada.
Uma implementação adequada deveria considerar os seguintes passos:
A implementação também deveria contemplar autenticação dos eventos, processamento idempotente, controlo de duplicados e mecanismos de repetição para falhas temporárias.
Os webhooks não eliminaram todas as necessidades de consulta direta às APIs.
O polling poderia continuar a ser utilizado quando a plataforma não disponibilizasse webhooks para determinado evento, quando fosse necessário reconciliar dados ou quando existisse uma necessidade específica de verificação periódica.
A escolha deveria depender da arquitetura da integração e das características do sistema de origem.
O objetivo não foi eliminar todas as consultas às APIs, mas garantir que cada chamada tinha uma finalidade operacional clara.
[15:12] O episódio destacou que as consequências das integrações sem governança ultrapassaram os custos tecnológicos.
A ausência de controlo sobre credenciais, servidores e destinos dos dados poderia expor informações estratégicas da empresa, comprometer a continuidade operacional e dificultar a investigação de incidentes.
André Cruz chamou a atenção para uma situação particularmente preocupante: a permanência de credenciais de API associadas a profissionais que já não trabalhavam na organização.
Quando um profissional desenvolveu uma integração utilizando credenciais pessoais ou associadas à sua conta, a empresa poderia continuar dependente desses acessos mesmo depois da sua saída.
Se as credenciais não fossem revogadas, a organização perderia parte do controlo sobre quem poderia consultar ou alterar informações.
Este cenário também dificultaria a atribuição de responsabilidades, a auditoria de operações e a identificação de acessos indevidos.
Para reduzir o risco, a empresa deveria ter implementado:
A saída de um colaborador deveria desencadear um processo formal de revisão e revogação dos acessos, sem depender da memória da equipa ou de procedimentos informais.
[16:48] André Cruz alertou para o risco de automações executadas em servidores pessoais, contas individuais de cloud ou ambientes que a organização não conseguia supervisionar.
Uma integração poderia ter sido criada para resolver um problema operacional específico, mas continuar a executar processos sem documentação, responsável definido ou monitorização.
O risco aumentava quando esses sistemas armazenavam dados de clientes ou mantinham credenciais com permissões alargadas.
Entre os pontos que a empresa precisava de controlar estavam:
A centralização da gestão das automações permitiu reduzir a dependência de infraestruturas desconhecidas e melhorar a capacidade de resposta a incidentes.
[17:37] O episódio chamou a atenção para a circulação de bases de dados com nomes, contactos, histórico de compras e informações de faturação.
Quando uma integração enviava estes dados para destinos sem controlo adequado, a empresa poderia perder visibilidade sobre a sua utilização, armazenamento e partilha.
O risco não se limitou a acessos maliciosos. Um profissional poderia expor informação acidentalmente ao utilizar um servidor desprotegido, publicar uma chave num repositório ou configurar incorretamente as permissões de uma aplicação.
Noutros cenários, o acesso indevido poderia permitir a cópia de informações comerciais e a sua utilização para fins não autorizados.
Para um negócio digital, a exposição de dados poderia comprometer a confiança dos clientes, a reputação da marca e a continuidade da operação.
[19:51] André Cruz explicou que a Digital Manager Guru tinha adotado mecanismos de controlo para restringir e registar o acesso às contas dos clientes.
O exemplo apresentado destacou a importância de conhecer quem acedeu à informação, quais as operações realizadas e que alterações foram efetuadas.
A rastreabilidade permitiu que a organização investigasse ocorrências, identificasse comportamentos inesperados e reduzisse a dependência de acessos informais.
Uma estratégia de governança deveria, por isso, contemplar registos de auditoria, revisão periódica das permissões e procedimentos claros para a concessão de acessos.
O controlo das integrações também esteve relacionado com a proteção dos dados pessoais e com as obrigações legais aplicáveis ao negócio.
No contexto brasileiro, a LGPD tornou especialmente relevante a avaliação dos dados tratados, das finalidades de utilização, das permissões de acesso e das medidas de segurança adotadas.
A conformidade não dependeu apenas da existência de políticas formais. Também exigiu que os processos tecnológicos fossem configurados e supervisionados de acordo com essas políticas.
Por isso, a gestão das APIs e das automações deveria fazer parte da estratégia de segurança e proteção de dados da organização.
[24:54] André Cruz relacionou a adoção da inteligência artificial com a necessidade de reforçar os critérios de qualidade no desenvolvimento de software.
As ferramentas de IA facilitaram a criação de scripts, integrações e automações. Contudo, a capacidade de gerar código funcional não garantiu que a solução tivesse uma arquitetura adequada, fosse segura ou estivesse preparada para operar em grande escala.
O problema surgiu quando a rapidez da implementação foi confundida com a qualidade da solução.
Uma rotina poderia executar corretamente uma operação simples e ainda apresentar limitações importantes.
Entre os aspetos que exigiram atenção estiveram:
Segundo a perspetiva apresentada no episódio, a qualidade do resultado dependia também da capacidade de quem orientava a ferramenta para definir os requisitos, o contexto e as restrições técnicas.
Uma solução gerada por IA deveria, portanto, passar por revisão técnica, testes e validação antes de ser integrada nos processos críticos do negócio.
[25:05] André Cruz defendeu que a inteligência artificial poderia amplificar as limitações existentes quando era utilizada sem conhecimento técnico suficiente.
Se uma pessoa não compreendesse os requisitos de uma integração, poderia solicitar uma solução aparentemente simples que ignorasse aspetos fundamentais de segurança, escalabilidade ou manutenção.
A velocidade de desenvolvimento tornava possível replicar esse padrão em várias áreas da empresa, aumentando o impacto potencial dos erros.
O problema não esteve na utilização da IA em si, mas na ausência de critérios para avaliar o resultado produzido.
[26:48] — O episódio apresentou a preparação de regras e orientações internas como parte do processo de adoção da IA na Digital Manager Guru.
Estes mecanismos, frequentemente designados guardrails, ajudaram a definir limites, padrões e procedimentos para o desenvolvimento e a utilização de ferramentas automatizadas.
Numa organização, essa abordagem poderia incluir:
A inteligência artificial aumentou a velocidade de desenvolvimento, mas a responsabilidade pela segurança e pela qualidade continuou a pertencer à organização.
[30:04] André Cruz apresentou um conjunto de práticas para reduzir o desperdício, melhorar a segurança e aumentar o controlo sobre as integrações.
A implementação não exigiu que a empresa eliminasse as automações existentes. O objetivo consistiu em identificar os processos em funcionamento, corrigir as ineficiências e estabelecer regras que permitissem gerir as integrações de forma sustentável.
30:15 — A primeira recomendação consistiu em utilizar notificações de eventos sempre que a plataforma disponibilizasse esse mecanismo.
Em vez de consultar continuamente uma API para verificar se existiam alterações, a empresa poderia receber um webhook e utilizar a API para obter os dados adicionais necessários.
Para os processos que exigissem consultas periódicas, a estratégia deveria privilegiar a sincronização incremental.
[31:05] André Cruz exemplificou esta abordagem com a consulta dos dados criados, alterados, aprovados ou cancelados durante um determinado período.
Em vez de descarregar novamente todo o histórico de vendas, o sistema poderia consultar apenas os registos relevantes desde a última sincronização.
Esta prática reduziu o volume de dados transferidos e tornou o processo mais eficiente.
[33:04] O episódio destacou o cache como uma estratégia para evitar chamadas repetidas quando a informação não sofria alterações frequentes.
Dados como catálogos de produtos, ofertas e determinados parâmetros poderiam ser armazenados temporariamente, dependendo das necessidades do sistema.
Quando o dado fosse solicitado novamente, a aplicação poderia reutilizar a informação armazenada, evitando uma nova consulta desnecessária.
A implementação deveria considerar a validade do cache, a possibilidade de invalidar os dados quando o objeto de origem fosse alterado e os requisitos de consistência da informação.
O objetivo consistiu em reduzir o processamento redundante sem comprometer a atualidade dos dados.
[34:44] André Cruz recomendou um levantamento dos utilizadores e tokens de API ativos.
O inventário permitiu identificar quais as credenciais existentes, quem era responsável por cada uma e que sistemas dependiam delas.
Para tornar esse processo útil, a organização deveria registar, pelo menos:
Este levantamento deveria ser atualizado sempre que uma integração fosse criada, modificada ou desativada.
[35:06] O episódio destacou a necessidade de associar cada token a um responsável ativo e de rever os acessos quando existissem alterações na equipa.
A organização deveria evitar a utilização indiscriminada de contas administrativas e limitar as permissões ao que cada integração realmente necessitasse.
Uma política eficaz deveria incluir:
A gestão de credenciais deveria fazer parte dos processos normais de entrada, mudança de função e saída de colaboradores.
35:42 — André Cruz também recomendou uma revisão periódica dos webhooks existentes.
Endpoints antigos, configurações duplicadas e destinos que já não recebiam informação útil poderiam aumentar a complexidade da operação e dificultar a identificação de falhas.
A empresa deveria acompanhar a taxa de sucesso das entregas, os erros de processamento e a utilização efetiva dos endpoints.
Quando necessário, os webhooks poderiam ser corrigidos, desativados ou substituídos, de acordo com critérios operacionais definidos.
[36:31] A última recomendação técnica apresentada por André Cruz consistiu em centralizar a ingestão dos dados.
Em vez de criar múltiplos pontos de entrada independentes para receber a mesma informação, a empresa poderia utilizar um endpoint central para receber os eventos e encaminhá-los para os processos internos necessários.
Esta arquitetura facilitou a rastreabilidade e permitiu identificar em que etapa um evento tinha sido recebido, processado ou encaminhado incorretamente.
A utilização de filas também poderia ajudar a absorver picos de tráfego, permitir novas tentativas de processamento e reduzir a dependência entre os sistemas internos.
[34:44] As recomendações apresentadas no episódio permitiram estabelecer um plano inicial de auditoria para empresas que dependiam de APIs, automações e ferramentas de inteligência artificial.
A revisão deveria começar pelas integrações com acesso a dados financeiros, dados pessoais, transações e processos críticos para a operação.
Inventário e responsabilidades
[ ] Identificar todas as integrações e automações ativas
[ ] Mapear servidores, contas cloud e ambientes de execução
[ ] Atribuir um responsável técnico e de negócio a cada integração
[ ] Documentar a origem, o destino e a finalidade dos dados
Segurança e acessos
[ ] Listar tokens, chaves e credenciais de API ativos
[ ] Revogar acessos de pessoas que já não precisam deles
[ ] Rever permissões administrativas e aplicar o menor privilégio
[ ] Verificar o armazenamento de segredos e a exposição de chaves
[ ] Confirmar que os acessos relevantes ficam registados
Eficiência e arquitetura
[ ] Identificar consultas repetidas e descarregamentos integrais desnecessários
[ ] Avaliar a utilização de webhooks para eventos suportados
[ ] Implementar sincronização incremental sempre que adequada
[ ] Rever estratégias de cache para dados pouco voláteis
[ ] Verificar limites de utilização, tratamento de erros e recuperação
Monitorização e manutenção
[ ] Rever webhooks inativos, duplicados ou com elevada taxa de erro
[ ] Centralizar a receção e a distribuição de eventos quando adequado
[ ] Garantir documentação suficiente para manutenção por outra pessoa
[ ] Definir alertas, procedimentos de incidentes e revisões periódicas
[ ] Estabelecer regras para validar código e automações gerados por IA
Nem todas as integrações apresentaram o mesmo nível de risco. Por isso, a auditoria deveria priorizar os processos com maior impacto potencial no negócio.
Uma sequência inicial de trabalho poderia incluir:
Esta sequência permitiu tratar primeiro os riscos de maior impacto, sem exigir uma reconstrução imediata de todas as integrações existentes.
[37:47] André Cruz concluiu que a maturidade de um negócio digital não deveria ser medida pelo número de automações implementadas, mas pela capacidade da empresa para controlar os processos que funcionavam nos bastidores.
O episódio da Guru Talks demonstrou como integrações aparentemente funcionais poderiam gerar desperdício computacional, aumentar os custos operacionais, expor informações estratégicas e criar dependências difíceis de gerir.
A adoção de inteligência artificial e ferramentas low-code tornou a criação de soluções mais acessível. Contudo, a rapidez de implementação não substituiu a necessidade de arquitetura adequada, revisão técnica, gestão de acessos e manutenção contínua.
Para os empresários e gestores de negócios digitais, a prioridade deveria consistir em conhecer as integrações existentes, identificar os responsáveis, controlar as credenciais e garantir que os dados circulavam apenas pelos sistemas autorizados.
A utilização de webhooks, a sincronização incremental, o cache, a centralização da ingestão e a monitorização das operações representaram práticas importantes para reduzir ineficiências e melhorar a governança tecnológica.
Uma operação digital madura não depende apenas de automações rápidas. Depende de sistemas seguros, rastreáveis, eficientes e preparados para crescer sem comprometer a confiança dos clientes.
Para empresas que dependem de pagamentos, subscrições, CRM, checkout e múltiplas integrações, a governança de APIs deve ser tratada como parte da estratégia de crescimento, segurança e continuidade do negócio.
Não perca as próximas Guru Talks
CEO e fundador da Digital Manager Guru
Envolvido com análise de sistemas e grandes volumes financeiros desde 1999. Passou por empresas renomadas como Vivo, IG e VTEX. Sua atenção aos mínimos detalhes foram fundamentais em todos os projetos em que participou.
