Salesforce API versions 31.0–40.0: plan before support ends in Summer ’27

Salesforce has set out the next stage of its Platform API lifecycle. Versions 31.0 through 40.0 remain supported today, but will become deprecated and unsupported with the Summer ’27 release. Salesforce plans to retire and remove them in Summer ’28.

The long final deadline should not disguise the nearer operational change. Once an API version is unsupported, Salesforce says customers must upgrade it before Support will troubleshoot related cases, and those versions receive no bug fixes. Waiting until removal therefore means accepting a year in which a business-critical integration may still run but has a shrinking support position.

The sensible response is not a hurried search-and-replace exercise. It is a controlled inventory and upgrade programme: find real traffic, identify the owning application, understand its business purpose, test a supported version and retain evidence that the whole process still works.

What Salesforce has confirmed

The policy applies to requests made through Platform SOAP, REST and Bulk APIs using versions 31.0–40.0. Salesforce says these versions become deprecated and unsupported in Summer ’27. In Summer ’28, calls to them are expected to fail: REST with 410 GONE, SOAP with 500 UNSUPPORTED_API_VERSION and Bulk API with 400 InvalidVersion.

Salesforce’s active-retirements page currently places final retirement in June 2028, while the detailed article describes it as a release-based Summer ’28 event. Release changes occur when an org is upgraded, so platform owners should confirm the precise maintenance date for each org nearer the time rather than treat one calendar date as universal.

API version 31.0 dates from Spring ’14. The affected range can therefore hide in old middleware, scripts, desktop tools, packaged applications and integrations that have survived several ownership changes.

Salesforce also states what is not affected by this particular retirement: the API version saved on Apex classes, Apex triggers, Visualforce pages, Flows and Process Builder processes; versioned metadata components in managed packages; and custom Apex REST or SOAP web services. Those components may deserve their own technical-debt review, but their saved version is not evidence that they make an affected outbound request.

Separate this work from the SOAP login() retirement

Salesforce is also retiring the SOAP API login() operation in versions 31.0–64.0 in Summer ’27. The subjects overlap, but they are not the same change.

An integration could use SOAP login() on version 58.0 and be affected by the authentication retirement while sitting outside the 31.0–40.0 API-version range. Conversely, an application could obtain an OAuth token correctly and still call a REST version 39.0 endpoint. Track authentication method and requested API version as separate fields in the inventory so that fixing one does not create false confidence about the other.

Start with evidence from actual traffic

Salesforce recommends the API Total Usage event in EventLogFile to review SOAP, REST and Bulk API activity, including API version. In Setup, the Event Log Browser provides a practical route to download the data as CSV. Salesforce also documents a CLI and REST approach for retrieving the same files.

There is an important limitation: API-enabled organisations receive the previous 24 hours of API Total Usage data at no additional cost. Organisations with Event Monitoring can access 30 days, with options for longer retention. A one-day sample is useful, but it will miss weekly, month-end, quarter-end and seasonal jobs.

For that reason, Ostrelis recommends collecting daily files across a representative business cycle where practical. Filter for API_VERSION 40 and below, then use fields such as client name, user, source address, API family, resource and URI to group calls into likely applications. Shared integration users and shared network addresses can make attribution ambiguous, so confirm findings with application owners and supplier documentation.

Logs are only one line of evidence. Search source repositories and configuration for paths such as /services/data/v40.0/, SOAP endpoints, Bulk API version references and older libraries. Check Data Loader installations, Web Services Connector versions, Visualforce pages using the AJAX Toolkit, the retired SForceOfficeToolkit COM interface, older PHP toolkits, connected apps and middleware mappings.

Do not overlook outbound messaging callbacks

Salesforce highlights a less obvious dependency: an outbound-message listener can use the EnterpriseURL or PartnerURL in the payload to make a return SOAP call. An older outbound-message definition can therefore supply a legacy API endpoint even when the external listener code contains no obvious hard-coded version.

Salesforce advises either changing the client so it uses a version above 40.0 or recreating the outbound-message definition in Setup so that it is generated on a current version. This is a good example of why discovery must connect runtime evidence to Salesforce configuration rather than rely on code search alone.

Build an inventory that supports decisions

A useful register should include more than the API version. For each candidate, record:

• application, supplier and connected-app name;
• business process, data handled and operational criticality;
• production and non-production orgs;
• API family, version and observed resources;
• authentication method and integration user;
• last-seen date, frequency and peak processing window;
• business owner, technical owner and support route;
• upgrade path, test environment, target release and retirement decision.

Classify uncertain entries explicitly. “Seen but not attributed” and “known but not observed” are legitimate states that need investigation; they should not be silently converted to “not affected”. Low-frequency interfaces, disaster-recovery jobs and annual processes often matter precisely when they are hardest to reproduce.

Upgrade behaviour, not just the URL

For a simple REST client, moving to a current endpoint may appear to be a version-number change. That is only the start of testing. API responses, fields, validation behaviour, permissions, limits, pagination and library handling may have changed across many releases. SOAP consumers may require a new WSDL and regenerated client code. Older Data Loader or connector products may need a supported product upgrade rather than a local edit.

Use a maintained API version that the application and supplier support; do not move merely to 41.0 because it is the first version outside the retiring range. Then test with representative users and data. Prove authentication, reads, creates and updates, bulk processing, error handling, retries, callbacks, reconciliations and any downstream reporting. Compare record counts and business outcomes, not only HTTP success.

Where a vendor owns the integration, request the product version containing the fix, supported Salesforce API version, prerequisites, test guidance and production availability date. If the supplier cannot provide a credible route, the business owner needs enough time to replace or retire the dependency.

A practical delivery sequence

1. Set a baseline now. Download API Total Usage data and preserve it outside the short standard retention window.
2. Observe a representative cycle. Include month-end or other periodic workloads before declaring the inventory complete.
3. Reconcile evidence. Match traffic with source, middleware, Salesforce configuration, supplier records and the service catalogue.
4. Prioritise deliberately. Start with high-volume, business-critical, unowned and externally maintained integrations.
5. Choose a maintained target. Confirm the version is supported by both Salesforce and the relevant application or library.
6. Test end to end. Validate data and business outcomes under realistic permissions, volumes and failure conditions.
7. Cut over with monitoring. Record the change, watch API and transaction failures, reconcile outputs and define a time-bounded rollback decision.
8. Close with evidence. Retain the target version, test results, approvals, production timestamp and post-change observations.

The Ostrelis view

The Summer ’28 removal date provides planning room, not permission to defer ownership. Summer ’27 changes the support position first, and the hardest work is usually discovering who owns an old connection and how to test it safely.

Treat this as lifecycle management for an integration estate. Capture runtime evidence while it is available, distinguish endpoint versions from component metadata and authentication methods, retire what no longer serves a business purpose, and modernise the remainder through controlled releases. That approach reduces both deadline risk and the quieter operational risk of depending on software nobody can confidently support.

Ostrelis can help organisations inventory Salesforce API usage, coordinate application owners and suppliers, and deliver tested integration upgrades. See our Salesforce data and integration support, managed services and approach and experience. Need help getting prepared? Talk to a Salesforce expert.