A few days ago, I published my theory that the retirement of the SOAP API login() method would start affecting existing integrations in the upcoming Winter ’27 release, not just Summer ’27 as most people were assuming.

You called me crazy. You said nobody was telling us that.

Well... Today, I confirmed it.

Existing integrations using SOAP API login() can no longer authenticate in Winter ’27 unless the user has a new permission called Use Any API Auth.

You can find it in a permission set by navigating to:

Permission Sets → System Permissions → Use Any API Auth

Any user trying to authenticate using SOAP API login() without this permission will be rejected with the following error:

INSUFFICIENT_ACCESS: SOAP API login() requires the Use Any API Auth user permission

How to Find Who Is Still Using SOAP API login()

Before assigning the permission to anyone, you first need to identify which integrations are still using login().

Go to: Setup → Login History

You can review the records there or download the login history as a CSV file.

Look for entries where:

• Login Type is Other Apex API or Partner Product
• Login Subtype is SOAP API
• API Type is SOAP Enterprise, SOAP Partner or SOAP Tooling

Those entries represent applications authenticating through SOAP API login(). The Username tells you which Salesforce user is being used by the integration.

And don't be surprised if the Application field says N/A. That's expected. SOAP API login() isn't tied to a Connected App or External Client App, which is kind of the whole problem here.

If you need to investigate further, you can use the API Total Usage EventLogFile.

Look for events where:

• API_FAMILY = SOAP
• API_RESOURCE = login

The USER_NAME identifies the user, while CLIENT_NAME can help identify the actual application.

What You Should Do Before Winter ’27

Review your Login History and identify every user still authenticating through SOAP API login().

If you can't migrate those integrations just yet, create a dedicated permission set containing Use Any API Auth and assign it only to the users that actually need it.

That will keep those integrations alive through Winter ’27.

But don't get too comfortable with it. In Summer ’27, SOAP API login() in API versions 31.0 through 64.0 will be retired once and for all. At that point, there will be no permission you can assign and no checkbox you can enable to keep it alive a little longer.

As you might know, Salesforce is retiring the SOAP API login() method that external systems use to authenticate into your Salesforce organization.

It's a legacy method that some of your systems might still be using to get into Salesforce, and considering it's an extremely dumb and insecure way of doing it (just a plain username and password), it's indeed a good decision to get rid of it.

This enforcement is scheduled for Summer '27 and will make API versions 31.0 through 64.0 unavailable, returning an error saying:

And before you scroll away, STOP. Maybe your organization will stop working already after Winter '27.

The existing Salesforce documentation, as of the second I'm writing this post, is extremely confusing (as always) and might give us a hint that starting Winter '27, your users must have a specific permission to keep the SOAP API login() method working until Summer '27.

YES, I KNOW, PLEASE BEAR WITH ME!

Winter '26 Release Notes

This is an older release, from last year.

Back in a day, Salesforce publishes a release note saying that all versions starting from 65.0 won't have the SOAP API login() method working at all.

Reference: SOAP API | Salesforce Help

So far it makes sense.

Summer '26 Release Notes

The release right before Winter '27. This summer. Salesforce introduced a new checkbox under User Interface named "Enable SOAP API login() to users with the Use Any API Auth user permission".

Activate it, and the SOAP API login() method stops working for all users EXCEPT those who have the Use Any API Auth permission. That permission is also a new one, introduced in this very release.

Reference: Restrict Login Access to SOAP API | Salesforce Help

They allow us to do a round of testing.

Winter '27 Release Notes

And then in the upcoming Winter '27 release notes, I quote: "To authenticate with the SOAP API login() operation, all users must have the Use Any API Auth user permission assigned to them".

If my interpretation is correct, it means that all your SOAP API login() integrations will break not in Summer '27 as you all assume, but literally in a few weeks with Winter '27, unless you assign that permission.

You might say I am overreacting, but why would you then publish this release page in the first place? Like, the checkbox is there, the permission is there, there is nothing new unless you now enforce having this permission attached. Just look at the reference.

Reference: Assign Use Any API Auth Permission for SOAP login()

My detective conclusion

Winter '27 will break your SOAP API login() integrations and will give you a way to repair them quickly. The problem is, if it weren't for me, you would still be in for the downtime.

On that note, I recommend looking into this already today. To identify all SOAP API usage, you shall:

• Look into your inbox. Salesforce must have sent you an email a couple of months ago saying that they identified that your org has been accessed using SOAP API login().
• Go to Login History and look for "Other Apex API", "Partner Product" or "SOAP API". If any of these are present, you can track back the user and then see which integration is using this older authentication method.

• Finally, verify that all your AppExchange packages are updated and not using those older authentication methods. This is really easy to overlook, as you usually don't think of it.

To help you communicate with other teams, share with them that their code most likely looks something like this:

ConnectorConfig config = new ConnectorConfig();

config.setUsername("integration@example.com");
config.setPassword("passwordSECURITY_TOKEN");
config.setAuthEndpoint("https://YourDomainName.my.salesforce.com/services/Soap/c/41.0/");

The idea behind such integrations is simple. If your external application is accessing Salesforce with a username and password only — that's bad. It's either SOAP API login() or OAuth username-password, both of which are on their way out as we speak.

I'll keep you updated once we get Winter '27 in our sandboxes and whether my detective masterpiece is truthful.

While working with AI Agents, there is a popular saying: "Never trust one model to behave exactly like another".

This is my saying. It's not popular yet, but now it's destined to be.

On October 20, 2026, Google retires Gemini 2.5 Pro, 2.5 Flash, and 2.5 Flash-Lite. Salesforce documents the change in the Winter '27 release notes: requests to those models get rerouted automatically.

You should pay attention if you're using:

• Agentforce agents or subagents with an Agent Script model_config pointing to one of the older Gemini 2.5 models.
• Prompt Builder templates using Gemini 2.5.
• Custom solutions using the Models API with Gemini 2.5.

If your org just runs the Salesforce Default model option for Agentforce, you're out of scope. This is about the places where somebody explicitly chose Gemini.

So if you're using any of these models, test your prompts and Agentforce behavior against the replacement models before the reroute. And if the results disappoint you – choose your own target instead of inheriting the default one.

For agents specifically, Salesforce calls out GPT 4.1, Claude Haiku 4.5 and Gemini 3.5 Flash as the models it has "thoroughly" tested.