O Winter '27 chega em ondas entre agosto e outubro de 2026, e por baixo das novidades de tela vem um pacote de mudanças de autenticação e de URL de API que não avisa antes de derrubar uma integração. A falha não é um erro bonito na sua aplicação, é uma conexão que para na camada de rede, e o pior é que dá para descobrir isso agora, num sandbox, ou descobrir depois, num sábado, com o cliente ligando.
O Winter '27 aperta a autenticação da API em três frentes. O login() do SOAP API passa a exigir a permissão Use Any API Auth neste release. O fim das URLs de instância (na139) foi adiado para o Spring '27, mas dá para testar agora. E o fluxo username-password de OAuth morre em 20 de fevereiro de 2027.
O que muda de fato no Winter '27
Toda release do Salesforce vem embrulhada em novidades de tela, e é fácil ignorar a parte chata que fica no rodapé das notas: os "release updates" de segurança, que enforce sozinhos numa data marcada, sem depender de você clicar em nada. O Winter '27 chega em ondas de upgrade de produção em 29 de agosto, 5 de setembro, 3, 9 e 10 de outubro de 2026, e traz três mudanças que atingem quem integra a org com outro sistema.
A primeira é a exigência da permissão Use Any API Auth para o login() do SOAP API, que passa a valer neste release. A segunda é o fim das URLs de instância no tráfego de API, o item chamado Update Instanced URLs in API Traffic, que foi adiado de novo e agora está previsto para enforce no Spring '27. A terceira é a aposentadoria do fluxo username-password do OAuth, remarcada para 20 de fevereiro de 2027. As três compartilham a mesma característica cruel: a integração para de funcionar de repente, na data do enforcement, e o erro acontece antes da sua aplicação sequer tentar processar a resposta. Se você já apanhou de webhook e autenticação numa integração de assinatura, reconhece o padrão: o que quebra não é a lógica, é a porta de entrada.
URLs de instância: por que na139.salesforce.com vai parar
Toda org do Salesforce nasceu num servidor físico com um nome, o famoso hostname de instância no formato na139.salesforce.com, ap5.salesforce.com, eu17.salesforce.com. Durante anos foi comum uma integração ser configurada apontando direto para esse endereço, porque era o que aparecia na barra do navegador no dia em que alguém montou a conexão. O problema é que a org não fica presa a esse servidor. A Salesforce move orgs entre instâncias em manutenções e migrações, e quando isso acontece o hostname antigo deixa de corresponder à sua org.
O My Domain resolve isso. Ele é o seu endereço estável, algo como suaempresa.my.salesforce.com, que aponta para a org onde quer que ela esteja fisicamente. O Update Instanced URLs in API Traffic é a mudança que passa a recusar chamadas de API fixadas no hostname de instância antigo, forçando todo mundo a usar o My Domain. Esse item já foi adiado três vezes e agora está marcado para enforce no Spring '27, não no Winter '27. Isso é uma boa notícia e uma armadilha ao mesmo tempo: você ganhou tempo, e é exatamente por ganhar tempo que a maioria vai esquecer e ser pega no sábado do enforcement.
A falha é o detalhe que assusta. Quando enforce, a chamada para o hostname antigo não volta com um 401 educado nem com um corpo de erro em JSON. Ela morre na camada de rede, antes de a autenticação ser tentada. Do lado do seu middleware, é timeout ou conexão recusada, o tipo de erro que manda o time caçar firewall por horas antes de alguém desconfiar de uma URL velha.
Como achar as chamadas em risco antes que parem
A caça tem duas partes, e as duas você consegue fazer hoje. A primeira é procurar o hostname antigo em todo lugar que fala com o Salesforce. Faça uma busca por padrão de instância nos repositórios de código, nos exports de configuração do middleware, nas coleções de Postman, nos scripts de integração e em qualquer connected app documentado. Um grep simples já pega a maioria:
grep -rEn '[a-z]{2,3}[0-9]+\.salesforce\.com' .Esse padrão casa com na139, ap5, cs42 e companhia, e ignora o seu My Domain, que tem o my no meio. Tudo que aparecer é candidato a troca: substitua o hostname de instância pelo endereço do My Domain da org. Se a sua integração usa o endpoint retornado no login, garanta que o código respeita o instance_url que vem na resposta de OAuth em vez de ter um host chumbado.
A segunda parte é testar de verdade, e aqui o Salesforce dá uma ferramenta boa. Existe uma configuração de My Domain que bloqueia o tráfego de URL de instância sob demanda. Você liga esse bloqueio num sandbox, força a falha ali no controle, roda a bateria de integrações e vê o que quebra sem risco para produção. Depois desliga, corrige o que apareceu e agenda a virada de produção para uma manhã de terça, no seu horário, em vez de esperar o enforcement automático cair num fim de semana. Forçar a falha de propósito, num ambiente seguro, é a diferença entre um teste de meia hora e um incidente. É a mesma disciplina de quem não confia na sorte e versiona e testa relatório e dashboard no Git antes de mexer em produção.
O login() do SOAP API e a permissão Use Any API Auth
Essa é a mudança que enforce agora, no Winter '27, e por isso merece prioridade sobre a das URLs. Muita integração legada autentica pelo login() do SOAP API, o método antigo em que você manda usuário e senha num envelope XML e recebe de volta um session id. A partir do Winter '27, qualquer usuário que autentique por esse login() precisa ter a permissão de usuário Use Any API Auth. Sem ela, a autenticação é recusada, e a integração que rodava há anos simplesmente para de logar.
Há duas saídas, e elas apontam para direções opostas. A rápida é conceder Use Any API Auth ao usuário de integração, o que mantém a conexão viva sem reescrever nada. A certa é aproveitar o empurrão para sair do login() por SOAP e migrar para OAuth com Named Credential, que é o caminho que o Salesforce quer que todo mundo tome. Se a integração já está de pé e você precisa dela funcionando na segunda-feira, conceda a permissão agora e planeje a migração. Empurrar a org para reescrever tudo de véspera é o tipo de pressa que gera bug, e a honestidade aqui é dizer que a permissão compra tempo sem dívida técnica nova, desde que a migração entre no roadmap de verdade.
Vale saber para onde a coisa vai: o login() do SOAP nas versões de API 31.0 a 64.0 está marcado para ser retirado no Spring '27. Ou seja, a permissão do Winter '27 é o primeiro aperto, e a aposentadoria da versão vem logo atrás. Quem trata isso como um ajuste pontual vai fazer o mesmo trabalho duas vezes.
O fim do fluxo username-password: 20 de fevereiro de 2027
O terceiro item não é do Winter '27 em si, foi remarcado para 20 de fevereiro de 2027, mas entra aqui porque atinge exatamente o mesmo tipo de integração e convém corrigir de uma vez. O fluxo username-password do OAuth, o grant_type=password, é aquele em que o middleware posta usuário, senha e security token direto no endpoint de token e recebe um access token. É simples, funciona, e é justamente por ser simples que a Salesforce está matando: guardar senha em texto no middleware é um dos jeitos mais frágeis de autenticar que existem.
A migração é para um fluxo de OAuth que não carrega senha. O JWT bearer, com um certificado no connected app, é o mais comum para integração server-to-server, e o client credentials serve quando um usuário de execução dedicado resolve. Em qualquer um dos dois, o segredo sai do código e vai para um Named Credential, que guarda a credencial fora do Apex e cuida do refresh do token sozinho. Se você fizer só uma coisa deste artigo, que seja parar de espalhar senha e security token em arquivo de configuração, pelo mesmo motivo que se aplica a CRUD, FLS e sharing no Apex: a superfície de risco não é a lógica, é onde o segredo mora.
Quando muda, o que fazer
Junte as três frentes numa tabela e a ordem de prioridade fica óbvia: resolve primeiro o que enforce mais cedo.
| Mudança | Quando enforce | O que quebra | O que fazer |
|---|---|---|---|
| login() do SOAP exige Use Any API Auth | Winter '27 (agora) | Login por SOAP do usuário de integração | Conceder a permissão ou migrar para OAuth |
| Fim das URLs de instância (na139) | Spring '27 | Chamada fixada em hostname de instância | Trocar por My Domain, testar com o bloqueio |
| Fim do fluxo username-password | 20 fev 2027 | grant_type=password no middleware | Migrar para JWT bearer ou client credentials |
| Retirada do login() SOAP v31 a 64 | Spring '27 | Chamada SOAP em versão antiga | Subir a versão de API ou sair do SOAP |
A leitura da tabela é uma sequência, não uma lista de tarefas soltas. A permissão Use Any API Auth é o incêndio da vez, porque enforce neste release. As URLs de instância e a retirada da versão do SOAP vêm no Spring '27, e o fluxo de senha em fevereiro. Se você tratar as quatro como um projeto único de "tirar a integração do legado", faz uma vez o trabalho que, feito aos pedaços, você faria três.
O que fiz na Vetra para não ser pego
A Vetra Distribuidora é a empresa fictícia que uso como org de demonstração deste portfólio, e ela tem integrações de verdade rodando: geração de proposta em PDF, um webhook de assinatura eletrônica e um par de chamadas para serviço externo. Quando as notas do Winter '27 saíram, tratei a org como se fosse a de um cliente e rodei o mesmo diagnóstico que recomendo aqui.
O grep pelo padrão de instância voltou limpo, porque as integrações já usavam Named Credential apontando para o My Domain, não para hostname físico. Onde havia dívida era no jeito de autenticar: uma das chamadas de teste ainda usava um fluxo de senha herdado de um exemplo antigo. Troquei por JWT bearer com o segredo no Named Credential, o que de quebra tirou uma credencial que estava dormindo num campo de configuração. O login() por SOAP não existia na Vetra, então a permissão Use Any API Auth não me pegou, mas foi o primeiro item que fui conferir, porque é o que enforce agora.
A lição que levo para o cliente é a mesma de sempre: release do Salesforce não é só recurso novo, é uma lista de coisas que vão parar de funcionar numa data marcada, e essa lista mora na parte que ninguém lê. Ler as notas com um olho nos "release updates", apontar as integrações para o My Domain e guardar segredo em Named Credential transformam esse tipo de anúncio de susto em rotina. Se você quer comparar o ritmo dessas mudanças, o resumo do Summer '26 para dev mostra que o aperto na autenticação não é evento isolado, é a direção.
Perguntas frequentes
O Winter '27 vai quebrar minha integração com o Salesforce?
Pode quebrar se ela ainda usa URL de instância antiga (como na139.salesforce.com) ou o login() do SOAP API sem a permissão certa. A mudança do login() por SOAP passa a exigir a permissão Use Any API Auth já no Winter '27. O fim das URLs de instância foi adiado para o Spring '27, mas o Winter '27 é a janela para testar e corrigir num sandbox antes que enforce em produção.
O que é a URL de instância e por que na139.salesforce.com vai parar?
URL de instância é o hostname físico do servidor onde sua org rodava, no formato na139.salesforce.com ou similar. A Salesforce está aposentando esse endereço em favor do seu My Domain (algo como suaempresa.my.salesforce.com), que aponta para a org onde quer que ela esteja. Chamadas fixadas no hostname antigo deixam de ser suportadas quando o Update Instanced URLs in API Traffic enforce, previsto para o Spring '27.
O que é a permissão Use Any API Auth do Winter '27?
É a permissão de usuário que passa a ser exigida para autenticar pelo login() do SOAP API no Winter '27. Sem ela, o usuário de integração que faz login por SOAP tem a autenticação recusada. A correção é conceder Use Any API Auth ao usuário de integração ou migrar a autenticação para OAuth com Named Credential.
Quando o fluxo username-password de OAuth para de funcionar?
Em 20 de fevereiro de 2027. O fluxo grant_type=password, em que o middleware manda usuário, senha e security token direto para o endpoint de token, é um dos mais fracos do OAuth e está sendo aposentado. A saída é migrar para o fluxo JWT bearer ou client credentials, guardando o segredo num Named Credential em vez de no código.