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 coincide com mudanças de autenticação e tráfego de API, mas seus escopos e cronogramas diferem. A exigência de Use Any API Auth depende de criação/configuração da org; URLs de instância têm calendário gradual até Spring '27; e a data publicada para desativação do fluxo username-password é 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 de Use Any API Auth para login() SOAP em orgs recém-criadas após ativação da configuração correspondente; em orgs existentes, a ativação é opcional. A segunda é Update Instanced URLs in API Traffic, com testes e enforcement gradual por instância até Spring '27. A terceira é a desativação planejada do fluxo username-password OAuth, publicada para 20 de fevereiro de 2027. Os sintomas variam conforme a mudança e a integração; teste os fluxos afetados em sandbox. Se você já apanhou de webhook e autenticação numa integração de assinatura, reconhece o padrão: o que quebra não é necessariamente 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 é o endereço da org independente de seu host físico. Update Instanced URLs in API Traffic trata chamadas de API fixadas no hostname de instância antigo. A página oficial consultada descreve teste e enforcement gradual por instância: sandboxes a partir de outubro/novembro de 2026 e produção de janeiro a março de 2027. Consulte o cronograma da sua instância; não há uma única data universal. A alegação de que o item foi adiado três vezes não foi confirmada na fonte consultada.
O comportamento depende do rollout e do ambiente. A documentação consultada descreve respostas de erro ao bloquear tráfego de URL de instância; não trate como timeout ou falha de rede universal. Faça o teste controlado no sandbox e observe a resposta concreta do seu cliente.
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
O escopo da mudança não é universal. A documentação consultada diz que, em orgs recém-criadas após habilitar a configuração de login SOAP, usuários precisam da permissão Use Any API Auth; em orgs existentes, habilitar a configuração é opcional. Verifique a configuração e o usuário efetivamente usados antes de alterar integrações.
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: a documentação consultada indica que SOAP login nas versões de API 31.0 a 64.0 será desativado no Summer '27, não Spring '27. Planeje a migração conforme o aviso e cronograma oficiais.
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 adequado ao cenário. Para servidor-a-servidor, avalie client credentials; para acesso delegado de usuário, avalie o fluxo web-server com PKCE. Não há uma única substituição correta para todas as integrações; valide autenticação e gestão de credenciais conforme a arquitetura. 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 |
|---|---|---|---|
| Use Any API Auth no login() SOAP | Conforme ativação/configuração da org | Login SOAP afetado pela configuração | Verificar configuração e permissão efetiva |
| URLs de instância (na139) | Rollout gradual por instância até Spring '27 | Chamada fixada em hostname de instância | Trocar por My Domain e 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 | Summer '27 | Chamada SOAP em versão antiga | Subir a versão de API ou sair do SOAP |
A tabela reúne datas e escopos diferentes, que devem ser conferidos para cada org e integração. Use o cronograma oficial de rollout para URLs e confirme as datas vigentes antes de planejar mudanças.
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 haver impacto conforme a configuração. A exigência de Use Any API Auth para login() SOAP depende da ativação/configuração da org; URLs de instância têm enforcement gradual por instância até Spring '27. Teste no sandbox e consulte o cronograma oficial.
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 exigência de Use Any API Auth para login() SOAP vale em orgs recém-criadas após habilitar a configuração correspondente; em orgs existentes, a ativação é opcional segundo a documentação consultada. Verifique a configuração antes de planejar a mudança.
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.