It’s good practice to ensure that your applications are using the latest API versions to get access to the latest capabilities, and it’s even more important to stay ahead of pending API version retirement. Back in 2021, Salesforce announced a comprehensive API version retirement plan for legacy Platform APIs. As part of that plan, Salesforce Platform API versions 21.0 through 30.0 are now deprecated and will be retired in the Summer ’25 release.
While this important topic has been covered in previous blog posts, this post highlights two new tools to help you prepare for this API version retirement by making it easier to identify client applications that are using these deprecated API versions. We’ll give you an overview of the Event Log Browser and API Version Retirement Enforcement, and walk through how to set each of them up. We’ll also cover some helpful best practices that can also enhance your efforts.
Monitor API Total Usage events
One of the ways that you can identify which API versions are being used in your apps is by monitoring the free API Total Usage events that report SOAP, REST, and Bulk API requests to your org.
To make monitoring easy, use the new Event Log File Browser included in the Summer ’24 release to browse the API Total Usage event log files on your org and download them as CSV files to view the individual API events. Here, you can view the daily event log files for the last 24 hours. If you have activated Event Monitoring, then you can view both hourly and daily event log files for the last 30 days.
You can access the event log data in a couple of simple steps.
From within Setup, navigate to Security → Event Monitoring → Event Log Browser.
You can then download the individual event log files as CSV files to view the API events in them.
Review each CSV file and determine if requests are being made to endpoints with API versions 30.0 and below.
For any application that consumes versions 30.0 and below, use the following key fields in the event log data to help identify the source of the API call:
CONNECTED_APP_IDindicates the connected app that made the API call.CLIENT_NAMEis an optional header provided by clients to help identify applications making the API calls.USER_IDidentifies the user in your org that is used to authenticated the API calls. While this can be helpful in identifying the originating client, be aware that the same system user account might be shared by multiple clients.CLIENT_IPis the IP address of the requesting client, but be careful if multiple clients from the same physical location share the same IP address.
You can also access the event log data via the API, and this is well described in the blog post An Important Update to Our Legacy API Retirement Plan.
Activate API Version Retirement Enforcement
A new feature in the Winter ’25 release allows you to activate the enforcement of the retirement of these deprecated API versions in your org. Once enabled, API requests to these versions will fail with the same error as you would see when the retirement is enforced in the Summer ’25 release.
- REST API will return HTTP status
410: GONE - SOAP API will return HTTP status
500: UNSUPPORTED_API_VERSION - Bulk API will return HTTP status
400: InvalidVersion
This helps you to identify any applications that are calling your org using these deprecated API versions as they will encounter an error. Given that this may — or probably will! — break the application’s behavior, this feature should be used with care. Temporarily forcing this breakage now will allow you to identify those applications using the deprecated versions and ensure that they are upgraded to the latest API version prior to the official retirement enforcement in the Summer ’25 release (when they will definitely break!).
Using this new feature
In Setup, navigate to Release Updates and select the Salesforce Platform API Versions 21.0 through 30.0 Retirement card. The Enable Test Run button will enable version retirement enforcement. The button name will change to Disable Test Run, which can be used to disable version retirement enforcement when your testing is complete.
Best practices to make it easier to identify who made API calls
Whether you are impacted by the retirement of these deprecated API versions or not, you should plan for future API version retirements. Being able to identify the applications making API calls to your org is just good API governance.
The following best practices can help you get to the source of calls to deprecated APIs, so you can make the appropriate updates before they officially retire.
Use Connected Apps
The best way to be able to identify the source of API calls is by using connected apps as this creates an explicit identity for each client application in your org. The connected app ID is logged with all API calls made by that application, making it straightforward to identify.
Specify a client name in all your API calls
Ensure that your client applications specify the client name in the Sforce-Call-Options request header in their API calls. This is an optional header value that can be populated with any text and is logged with all API calls made by that application to help identify it. This header value can be populated in API calls using the REST API, the SOAP API, and the Bulk API.
Create a dedicated user per integration with the Salesforce Integration user license
Salesforce recommends that each application connecting with your org has its own dedicated user. This allows you to only authorize each application to access the data and operations that it needs, and nothing more while providing distinct auditability and traceability of requests from each application. The user ID of that user is logged with API calls from the application, providing another means to identify the origination.
Salesforce introduced the Salesforce Integration user license as a cost effective means for each integration to have its own dedicated user. Read this blog post to learn how to configure the Salesforce Integration user license.
Conclusion
The Summer ’25 release is approaching — it will deploy to sandbox orgs in May 2025 and production orgs in June 2025 — and with it comes the official retirement enforcement of the deprecated Platform API versions 21.0 through 30.0. The two new tools and the best practices we covered in this post will make it easier for you to identify any applications using these versions, so that you can more easily upgrade them to newer API versions.
Further Resources
- Blog post: An Important Update to Our Legacy API Retirement Plan
- Blog post: Prepare for Legacy API Retirement in Summer ‘22
- Blog post: Make API Version Retirements a No-Op
- Documentation: Give Integration Users API Only Access
- Blog post: Invoke REST APIs with the Salesforce Integration User and OAuth Client Credentials
About the author
Jeremy Westerman is the Director of Product Management for Salesforce APIs. He is responsible for Salesforce APIs that access data on the core Salesforce Platform. You can find him on LinkedIn.