NotíciasSe algum sistema autentica no Salesforce com a operação SOAP login(), a equipe precisa revisar o acesso dos usuários até 1º de dezembro de 2026. A partir dessa data, toda conta usada por esse método precisa ter a permissão Use Any API Auth; sem ela, a autenticação falha. É uma mudança que pode interromper integrações antigas, ETL, middleware, scripts e produtos de terceiros. Chamadas REST ou OAuth que não usam SOAP login() não entram nessa exigência específica.
A mudança mais próxima: permissão em cada usuário
O Salesforce anunciou a exigência nas informações da versão Winter ’27 e a detalha na página oficial sobre a aposentadoria do SOAP API login() e novos requisitos de segurança. A regra alcança ambientes de produção e sandboxes: cada usuário que inicia uma sessão chamando login() precisa receber a permissão Use Any API Auth. Sem ela, o servidor rejeita a tentativa. O resumo de mudanças para desenvolvedores também coloca a aplicação da regra em 1º de dezembro.
Isso não quer dizer que toda chamada SOAP deixará de funcionar em dezembro. A alteração atinge o método de autenticação login(), que recebe usuário e senha e devolve uma sessão. Se uma aplicação obtém um token por OAuth e depois usa operações SOAP com esse token, o fluxo de autenticação é diferente. O guia técnico do método login() ajuda a identificar o ponto de entrada usado pelo cliente.
Também não é uma exigência geral para chamadas REST, Bulk API ou integrações que já autenticam por OAuth. Antes de alterar perfis ou permissões, confirme como cada conector abre a sessão e com qual usuário. Este guia da Pump sobre APIs e integrações apresenta as perguntas úteis para mapear a comunicação entre sistemas; aqui, a diferença decisiva é o método de autenticação.
Faça o inventário antes de conceder a permissão
Comece pelo histórico de login do Salesforce. A documentação recomenda filtrar eventos de aplicações por tipo de login SOAP e identificar os nomes de usuário envolvidos. Como complemento, o objeto API Total Usage EventLogFile pode mostrar chamadas cuja autenticação veio de SOAP login(); um campo CONNECTED_APP_ID vazio é um sinal para investigar esse caminho. A página de requisitos acima descreve essas consultas e os campos a conferir.
Depois, associe cada usuário a um sistema, responsável e rotina. Inclua processos raros: fechamento mensal, importações anuais, rotinas de contingência e integrações de fornecedores que não são executadas diariamente. Ver um usuário “API Enabled” no cadastro não prova, por si só, qual aplicativo o utiliza.
Atribua Use Any API Auth somente aos usuários que realmente precisam continuar chamando o método enquanto ele estiver disponível. O Salesforce orienta a conceder a permissão por perfil ou permission set. Prefira usuários de integração dedicados, valide as licenças que permitem receber essa permissão e registre por que cada conta precisa dela. Concedê-la em massa sem inventário pode manter um caminho legado habilitado para contas que não deveriam usá-lo.
Dezembro não é o fim da transição
Há pelo menos mais dois marcos para planejar. A partir de 15 de dezembro de 2026 em sandboxes e 31 de janeiro de 2027 em produção, logins SOAP vindos de faixas de IP amplas podem exigir security token ou autenticação mútua por certificado. O Salesforce também planeja desativar login() em organizações sem atividade desse método nos seis meses anteriores. Isso pode surpreender tarefas sazonais ou de recuperação de desastre que não aparecem em um teste semanal.
Por fim, na versão Summer ’27, o Salesforce vai retirar login() nas versões SOAP 31 a 64. Portanto, dar a permissão em dezembro é uma medida de continuidade de curto prazo, não uma migração definitiva. A recomendação do Salesforce é passar a autenticação para External Client Apps e OAuth 2.0. O guia oficial de autorização SOAP com OAuth diferencia os fluxos: JWT bearer ou client credentials para integrações sem interação humana; web server flow para aplicações conduzidas por uma pessoa. O resumo oficial das release notes de API confirma o requisito e a data de aplicação.
Se um conector pertence a um fornecedor, confirme com ele qual versão usa e quando suportará External Client Apps. Para código próprio, teste a nova autenticação em sandbox com o mesmo usuário, escopos e operações da produção; valide também renovação de tokens, secrets, IPs autorizados e monitoramento de falhas. A permissão nova não converte automaticamente usuário e senha para OAuth.
Um plano prático para as próximas semanas
- Procure
login()em código, jobs, ETL, ferramentas de sincronização e configurações de fornecedores. - Cruze os achados com Login History e API Total Usage; inclua rotinas sazonais.
- Atribua Use Any API Auth às contas confirmadas e teste em sandbox antes de 1º de dezembro.
- Planeje separadamente a migração para OAuth antes de Summer ’27 e os ajustes de IP/token dos cortes de dezembro e janeiro.
A visão geral de stack tecnológica ajuda a organizar quem mantém cada componente e quais dependências precisam ser verificadas. Esse cuidado é especialmente útil quando a integração foi contratada pronta e o código não está na equipe interna.
A ação imediata, portanto, é identificar apenas as integrações que iniciam sessão com SOAP login() e garantir a permissão para os usuários correspondentes. Em paralelo, trate OAuth como o destino da migração: manter a chamada funcionando em dezembro não evita a aposentadoria prevista para 2027.
