Salesforce API Versions 31.0–40.0 Retire June 2028: Admin Guide

Salesforce has confirmed that legacy Platform API versions 31.0 through 40.0 will be retired on June 1, 2028 (the Summer '28 release). After that date, REST, SOAP, and Bulk API requests that target those versions will stop working and return errors.

This is a different deadline from the SOAP API login() retirement scheduled for June 1, 2027. Both come from the same Salesforce product retirement notice, but they affect different things and have different timelines. This guide focuses on the API version 31.0–40.0 retirement and the practical steps admins and developers should take now.

The good news: 2028 sounds far away, but integrations are easy to forget and hard to inventory under deadline pressure. Starting an API usage audit early is the cheapest way to avoid a broken integration later.

Quick Answer

What it is: Salesforce is retiring Platform API versions 31.0 through 40.0 (REST, SOAP, and Bulk) on June 1, 2028. Any integration, middleware, custom code, or app that calls one of these older versions must be upgraded to a newer, supported version before then. Who it matters for: Salesforce admins, developers, integration owners, and any team running ETL tools, middleware, AppExchange packages, or custom callouts. The decision it supports: how to find which of your integrations use legacy API versions and plan remediation ahead of the deadline. Why Vantage Point is relevant: Vantage Point's senior, US-based consultants run legacy-API and integration health assessments that inventory old API callers and build a remediation plan, drawing on our Salesforce system integration and data migration practice.

TL;DR

• What changed: Salesforce Platform API versions 31.0–40.0 (REST, SOAP, Bulk) retire on June 1, 2028; requests to those versions will fail afterward.
• Why it matters: Hardcoded endpoints like /services/data/v34.0/ and older middleware connectors will break unless upgraded to a supported API version.
• Best for: Admins and developers who own Salesforce integrations, data tools, and custom Apex callouts.
• What to do: Use the API Total Usage event type and the Event Log Browser to find legacy callers, then upgrade endpoints, retest, and coordinate with vendors.
• How Vantage Point helps: We provide a legacy-API and integration health assessment plus managed services to remediate and retest old API callers before the deadline.

What Changed?

Salesforce is retiring Platform API versions 31.0 through 40.0. These versions map roughly to the Summer '14 through Summer '17 releases — code that, in many orgs, has been running untouched for years.

This is part of a long-running Salesforce API end-of-life program. Salesforce commits to supporting each API version for a minimum of three years, and it notifies customers at least one year before a version's support ends. Versions 7.0–20.0 were retired in Summer '22, and versions 21.0–30.0 were retired in Summer '25. The 31.0–40.0 group is simply the next batch on the schedule.

The retirement applies to all Salesforce orgs. It is not org-specific, edition-specific, or tied to any private account detail. If your org sends any request to one of these versions after the deadline, that request fails.

After June 1, 2028, requests to the retired versions return version-specific errors:

Why Salesforce Is Doing This

Retiring old API versions lets Salesforce improve security, performance, and supportability. Older versions lack modern API capabilities and security expectations, and maintaining them indefinitely slows platform innovation. Moving to a current, supported version also gives your integrations access to newer features and better long-term stability.

Who's Affected

Any system that hardcodes or defaults to an API version between 31.0 and 40.0 is at risk. Common examples include:

• Integrations and middleware — iPaaS connectors, point-to-point integrations, and reusable connection configs that pin an old version in the endpoint (for example, /services/data/v34.0/...).
• ETL and data tools — data loaders, backup/archive tools, and reporting/BI connectors that authenticate via SOAP or pull data via Bulk API on an old version.
• Custom code and Apex callouts — outbound callouts, Named Credentials, and external apps that build Salesforce URLs with a legacy version number.
• Legacy AppExchange and ISV packages — older managed packages that have not been updated by their vendor.
• Home-grown scripts — one-off automation, cron jobs, and admin utilities that nobody has touched in years.

The riskiest callers are usually the ones no one remembers building. That is exactly why an inventory matters more than a guess.

What You Need to Do

You can't fix what you can't see. The core workflow is: find legacy callers → upgrade endpoints → retest → coordinate with vendors.

Step 1: Find which API versions your org is calling

Salesforce gives you tools to identify old API traffic before it breaks:

• API Total Usage event type — The ApiTotalUsage event in the EventLogFile object reports SOAP, REST, and Bulk API requests and the version used. This is the single best source of truth for which versions your org actually receives.
• Event Log Browser — In Setup, go to Security → Event Monitoring → Event Log Browser, then download the API Total Usage logs as CSV and review the API version field. Look for any request at version 40.0 or below.
• Key identifying fields — In the log data, use CONNECTED_APP_ID, CLIENT_NAME, USER_ID, and CLIENT_IP to trace each legacy call back to the application or integration that made it.
• Connected Apps "API version" field — Review connected apps and external client apps to see which versions are configured.

Step 2: Watch for the Release Update enforcement test run

For previous API retirements, Salesforce published a Release Update card that let admins switch on a "test run" to enforce the retirement early in a sandbox or production org. When the equivalent card appears for the 31.0–40.0 retirement, use it in a sandbox first. It deliberately makes legacy calls fail so you can flush out hidden callers safely — well before the real deadline.

Step 3: Remediation checklist

• [ ] Pull at least 30 days of API Total Usage data and identify every request at version 40.0 or lower.
• [ ] Map each legacy caller to an owner: internal team, integration, or third-party vendor.
• [ ] Upgrade endpoints to a current supported API version and update Named Credentials, connector configs, and any hardcoded URLs.
• [ ] Open vendor/ISV tickets for managed packages or tools you can't change directly; confirm their upgrade timeline.
• [ ] Adopt good API governance: a dedicated integration user per integration, the Salesforce Integration user license where appropriate, and a Sforce-Call-Options client name on every call so future audits are easy.
• [ ] Retest each integration end to end in a sandbox after upgrading.
• [ ] Re-run the API Total Usage report to confirm zero traffic on retired versions.

For context on securing the integrations you upgrade, see our guide to API security best practices for CRM integrations.

Timeline

If your team is also planning for the login change, read our SOAP API login retirement readiness checklist. It covers the 2027 deadline that this post intentionally does not duplicate.

Official Salesforce resources

Verify the details and track status against the official Salesforce documentation:

• Salesforce API End-of-Life Policy — current support status by version.
• Salesforce Active Product & Feature Retirements — lists the 31.0–40.0 retirement for Summer '28.
• New Tools to Help Prepare for API Version Retirement — how to use the Event Log Browser and enforcement test run.

How Vantage Point Helps

Vantage Point is a mid-market Salesforce and HubSpot specialist staffed by senior, US-based consultants. We don't hand legacy-integration work to junior teams — the people who scope your assessment are the ones who do the remediation.

Through our system integration and data migration practice, we run a legacy-API and integration health assessment that inventories every API caller, flags anything on versions 31.0–40.0 (and below), maps each caller to an owner, and produces a prioritized remediation plan. For teams without bandwidth to execute, our managed services and ongoing support practice handles the endpoint upgrades, vendor coordination, and end-to-end retesting.

If you're modernizing integrations or tightening governance at the same time, we apply our VALUE Methodology to sequence the work so nothing breaks in production. Reach out for a legacy-API health check and get ahead of the 2028 deadline while the runway is long.

FAQ

Will my Salesforce integration break in 2028?

Only if it calls API versions 31.0 through 40.0. If your integrations already use a newer, supported version, they are unaffected. The safe move is to run an API Total Usage report now to confirm which versions your org actually receives, rather than assume.

How do I find which API version I'm using?

Use the API Total Usage event type in the EventLogFile object. In Setup, go to Security → Event Monitoring → Event Log Browser, download the logs as CSV, and check the API version field. Fields like CONNECTED_APP_ID, CLIENT_NAME, and USER_ID help you trace each call back to its source.

Does this affect Apex?

It can. Apex callouts and any code that builds a Salesforce API endpoint with a hardcoded version (for example, /services/data/v34.0/) need to be updated to a supported version. Apex code that uses internal DML and SOQL is not affected — this retirement is about external API requests using those version numbers.

What about managed packages from the AppExchange?

Managed packages that call legacy API versions are also affected, but you usually can't edit them directly. Identify the package in your API usage logs, then open a ticket with the vendor or ISV to confirm they will ship an update before June 1, 2028. If a vendor can't commit, plan for a replacement.

Is there a supported-version floor going forward?

After the 31.0–40.0 retirement, the lowest supported Platform API version becomes 41.0. Salesforce supports each version for at least three years and gives at least one year's notice before retiring a version, so expect future batches to keep moving the floor upward over time.

How is this different from the SOAP API login() retirement?

The SOAP login() retirement (June 1, 2027) removes a specific authentication call and pushes integrations toward OAuth. The API version 31.0–40.0 retirement (June 1, 2028) removes entire legacy versions of the REST, SOAP, and Bulk APIs. They are separate deadlines; an integration could be affected by one, both, or neither. Our SOAP API login readiness checklist covers the 2027 change in detail.

What happens if I do nothing?

After June 1, 2028, any request to a retired version fails: REST returns 410 GONE, SOAP returns 500 UNSUPPORTED_API_VERSION, and Bulk returns 400 InvalidVersion. That typically means broken data syncs, failed jobs, and silent integration outages — the kind that are painful to diagnose under pressure.

When should we start?

Now. The deadline is years out, but discovering every hidden caller, coordinating vendor updates, upgrading endpoints, and retesting takes time and competes with other priorities. Building the inventory early turns a fire drill into a routine maintenance task. Vantage Point's integration health assessment is a fast way to get a complete picture.