Updated - June 17, 2026
Original Publication Date - August 25, 2025
If you received the email titled “ACTION REQUIRED: Update Unsupported Platform SOAP API login(),” this article walks you through identifying which integrations triggered the email.
Salesforce is retiring SOAP API login() in API versions 31.0 through 64.0 with the Summer ’27 release and will end support at that time. To continue to authenticate your external applications, we recommend migrating to external client apps and OAuth. See this release note.
SOAP API login() in API versions 31.0 through 64.0 is currently supported.
SOAP API login() isn’t available in API versions 65.0 and later. See this release note.
SOAP API login() is disabled by default in newly created orgs. An admin must enable SOAP API login() in these orgs before it can be used. See this release note and documentation.
From the Summer ‘26 release, an additional admin control is in place to secure the use of SOAP API login(). In newly created orgs, once SOAP API login() is enabled, users must have the Use Any API Auth user permission to authenticate. This permission isn’t required for existing orgs; though admins can optionally enable and disable this enforcement. See this release note and documentation.
Note: API versions 30.0 and lower are already retired and unavailable.
To help customers protect their Salesforce accounts in the current threat landscape, Salesforce is adopting a secure-by-default posture for authenticating external applications. SOAP API login() does not provide that posture and is being retired. This requires applications that use SOAP API login() to migrate to external client applications and OAuth.
This retirement impacts any code, package, application, or integration that authenticates with a Salesforce org using SOAP API login().
In scope:
SOAP API login() calls to /services/Soap/c/<v>/ (Enterprise WSDL) and /services/Soap/u/<v>/ (Partner WSDL) where <v> is API version 31.0–64.0
Not in scope:
The Setup /soap/wsdl.jsp page (used to download WSDLs)
Managed-package WSDL version query parameters, such as ver_<package>=<n>
These Salesforce features use SOAP API login(). The products teams are aware of the SOAP API login() retirement.
Salesforce Connect Cross-Org Adapter (see this release note for details).
CRMA Connector will be migrated off SOAP API login() prior to the retirement.
These features will also be impacted in new orgs where SOAP API login() is disabled by default. Ensure that SOAP API login() is enabled per the instructions in this release note and documentation.
If you don’t upgrade the components and applications that use SOAP API login() by the Summer '27 retirement date, they won’t authenticate with your Salesforce org and all subsequent API calls made by those components and applications to your org will fail.
Identify the components and applications that use SOAP API login() to authenticate with your org.
Contact the developers and vendors to determine if the components and applications use SOAP API login().
Use Login History to identify applications that make SOAP API login() calls. Check which usernames logged in and contact those users to identify the application.
Use the API Total Usage EventLogFile to identify applications that authenticate using SOAP API login() from API calls that these applications make. Although Login History is the primary identification path, the API Total Usage EventLogFile can provide additional information to help identify applications.
If you custom developed the component or application, upgrade it to use external client apps and OAuth to authenticate.
For server-to-server or headless integration, use either the OAuth 2.0 JWT bearer flow or the OAuth 2.0 client credentials flow.
For browser-based or user-driven integration, use the OAuth 2.0 web server flow.
If the component or application is from a third-party vendor, contact the vendor to upgrade to the version that supports external client apps and OAuth.
To identify SOAP API login() calls made by applications, in Setup, go to the Login History page. You can review the entries online or download them to a CSV file.
Look for entries with:
LoginType “Other Apex API” or “Partner Product”, and
Login Subtype “SOAP API”, and
API Type “SOAP Enterprise,” “SOAP Partner,” or “SOAP Tooling”
These entries represent SOAP API login() calls by applications that need to be migrated. Contact the user listed in the Username field to identify the application.
The Application field shows “N/A” to indicate that the SOAP client isn’t bound to a connected app or external client app. This entry is intentional for the integrations targeted by this retirement. Data is not missing data.
In addition to using Login History, you can identify applications that use SOAP API login() to authenticate from the API calls they make by reviewing API events in the API Total Usage EventLogFile that report SOAP, REST, Bulk, ApexREST, and ApexSOAP API activity.
All users have access to the past 24 hours of the API Total Usage EventLogFile. If you have purchased and activated Event Monitoring, you have access to the past 30 days. You can increase this retention period up to 1 year in Event Monitoring Settings or by using EventSettings Metadata API.
To review the API events, download them to CSV files using one of these methods.
In Setup, go to Security → Event Monitoring → Event Log File Browser. Use the Event Log File Browser to locate the API Total Usage EventLogFiles. Download the individual log files as CSV files to view the API events.
Automatically download the API Total Usage EventLogFiles on a daily basis by using this tool. This is a Python script that retrieves the past 24 hours of data in the log files and downloads the events into CSV files. The Python script uses Salesforce CLI for authentication and data retrieval.
Manually use a client, such as Salesforce CLI, to run a SOQL query against the API Total Usage EventLogFile object.
sf data query -q "SELECT Id, LogFile, EventType, CreatedDate FROM EventLogFile WHERE EventType IN ('ApiTotalUsage')" -o <your-username>
For each result, perform a REST API request to the endpoints in the query result to retrieve the event log data in that event log file.
/services/data/v65.0/sobjects/EventLogFile/0AT3i000005vXpWGAU/LogFile
Paste the response body into an application to inspect the event log data as a CSV file.
The API events in the log files indicate authentication calls to SOAP API login(). These calls correspond to the SOAP API login() calls listed on the Login History page in Setup. Look for these entries.
API_FAMILY field: SOAP
API_RESOURCE field: login
USER_NAME field: user that the application authenticated
CLIENT_NAME field: optional header that client applications populate to identify themselves
Review all the API Total Usage events that have an empty CONNECTED_APP_ID field, which indicates that the application used either SOAP API login() or a Session to authenticate. Contact that user to identify the application and whether the application uses SOAP API login().
|
CONNECTED_APP_ID |
API call authenticated using …. |
|
Empty |
SOAP API login() or Session |
|
Populated |
Connected App Id (0H4 prefix) or External Client App (0xI prefix) |
Contact that user to identify the application and then investigate whether the application uses SOAP API login().
Yes. First use a sandbox to test integrations that have been migrated. In Setup, under Release Updates, find the SOAP API login() Retirement release update card. Select View Update. Select Enable Test Run. This feature blocks all SOAP API login() calls to the org, returning the same response as when the retirement is officially enforced. To re-enable SOAP API login(), select Disable Test Run.
Enabling a test run in production blocks all SOAP API login() calls for the duration of the test, which fails any integrations that have not yet been migrated.
Use this trail to learn how to use external client apps to build integrations.
If you have questions, open a case with support via Salesforce Help or contact your Salesforce account team. To view current and past retirements, see Salesforce Product & Feature Retirements.
For more information about Salesforce’s approach to retiring products and features, read our Product & Feature Retirement Philosophy.
Question: I received an email titled “ACTION REQUIRED: Update Unsupported Platform SOAP API
login(),” but SOAP API login() is disabled in my org. Why did I receive this email?
Answer: The email is sent to orgs where use of SOAP API login() was detected within the period specified in the email. If the org disabled SOAP API login() during or after that period, SOAP API login() calls detected during the period prior to SOAP API login() being disabled will trigger the email.
005132110

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.