> ## Content Index
> Fetch the complete content index at: https://www.bulkifiedthinking.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# SOAP API login() Is Breaking in Winter ’27 | I Was Right
- URL: https://www.bulkifiedthinking.com/posts/soap-api-login-is-breaking-in-winter27/
- Published: 2026-08-31T23:46:23.000Z
- Updated: 2026-08-31T23:46:23.000Z
- Description: SOAP API login() starts affecting existing Salesforce integrations in Winter ’27. Learn what changed, how the new Use Any API Auth permission works, how to identify affected integrations, and what you need to do before the final Summer ’27 retirement.
- Author: Andrii Sukhetskyi
- Tags: #beaware, #posts, Winter '27

A few days ago, I published [my theory](https://www.bulkifiedthinking.com/posts/soap-api-login-retirement-i-think-everyone-has-the-wrong-date/) 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**

![](https://storage.ghost.io/c/92/d5/92d55211-2cfe-45c9-b8c4-b7c7b1595cdb/content/images/2026/08/image-12.png)

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.

![](https://storage.ghost.io/c/92/d5/92d55211-2cfe-45c9-b8c4-b7c7b1595cdb/content/images/2026/08/image-13.png)

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.