# Salesforce Winter ’27: Simplify REST API Version Management with the latest Alias

A Salesforce REST API endpoint normally includes an API version:

```javascript
/services/data/v68.0/sobjects/Account
```

Winter ’27, which uses API version 68.0, adds another option. You can replace the numbered version with `latest`:

```javascript
/services/data/latest/sobjects/Account
```

Salesforce then routes the request to the most recently released REST API version supported by the org.

That distinction matters. `latest` is not another name for `v68.0`. It is an alias whose resolved API version can change as the target org supports newer REST API versions.

## What Changed in Winter ’27?

Before this change, the version segment of a REST API URI used a numbered API version:

```typescript
/services/data/v68.0/query
```

Winter ’27 also supports:

```javascript
/services/data/latest/query
```

The practical difference is version selection:

| Numbered version | `latest` |
| --- | --- |
| `/services/data/v68.0/...` | `/services/data/latest/...` |
| Client specifies the API version | Salesforce resolves the API version |
| Remains on that version until the URI changes | Resolves to the most recently released version supported by the org |
| Version upgrades are explicit | Version can advance without changing the client URI |

Numbered API versions remain supported. `latest` is an additional option, not a replacement.

## How `latest` Resolution Works

Salesforce documents `latest` as an alias that automatically resolves to the most recently released API version.

Consider:

```javascript
https://MyDomainName.my.salesforce.com/services/data/latest/sobjects/Account
```

For a Winter ’27 org whose most recently released supported REST API version is 68.0, `latest` resolves to that version.

Conceptually:

```plaintext
/services/data/latest/...
        |
        v
Target Salesforce org
        |
        v
Most recently released supported API version
        |
        v
REST resource
```

The important part is what happens as Salesforce releases advance.

If the target org later supports a newer REST API version, the same `/latest/` URI can resolve to that newer version. The client URI doesn’t need to change.

Compare that with:

```javascript
/services/data/v68.0/sobjects/Account
```

Here, the client explicitly asks for `v68.0`.

So this feature isn’t really about shortening an endpoint. It gives developers a choice between explicit and automatically resolved API version selection.

## Check the REST API Versions Available in an Org

Salesforce provides the Versions resource:

```javascript
/services/data/
```

It lists the REST API versions currently available, including each version, label, and root URL.

You can call it with:

```javascript
curl "https://MyDomainName.my.salesforce.com/services/data/"
```

Salesforce documents that this resource doesn’t require authentication.

A response contains entries such as:

```json
[
  {
    "label": "Winter '27",
    "url": "/services/data/v68.0",
    "version": "68.0"
  }
]
```

The real response can contain multiple supported versions.

This is useful when working with `latest` because you can inspect which REST API versions the target org currently exposes rather than assuming every environment is on the same version.

## Using `latest`

No additional REST syntax is required.

A request with an explicit version Usage:

```javascript
curl \
  "https://MyDomainName.my.salesforce.com/services/data/v68.0/sobjects/Account" \
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

The Winter ’27 alternative:

```javascript
curl \
  "https://MyDomainName.my.salesforce.com/services/data/latest/sobjects/Account" \
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

> In Bash, `\` continues the command onto the next line.

Using `latest` doesn’t change REST API authentication. Salesforce REST resources still require the access and authorization appropriate for the resource being called.

Salesforce also documents that users making API calls need the `API Enabled` permission. No separate enablement step is documented for the `latest` alias.

## When `latest` Is Useful

`latest` is useful when a client intentionally wants to follow the most recently released REST API version supported by the target org.

For example, a development utility that works across Salesforce environments could use:

```javascript
/services/data/latest/...
```

instead of maintaining a numeric version in its endpoint.

The client delegates REST API version selection to Salesforce.

That can reduce version maintenance, but only when automatically following the newest supported version is the behavior you want.

## When I Would Keep a Fixed Version

I wouldn’t automatically replace every numbered REST API endpoint with `latest`.

Consider a production integration that has been tested against:

```javascript
/services/data/v68.0/query
```

Keeping `v68.0` makes the API version explicit. Moving the integration to another version can then be handled as an intentional change that can be tested before deployment.

With:

```javascript
/services/data/latest/query
```

the URI stays unchanged while the version Salesforce resolves can advance as the target org supports newer releases.

That is documented behavior and the main architectural trade-off of this feature.

From a development perspective, I would consider `latest` when:

*   The client is intended to follow the newest REST API version supported by the org.
    
*   Avoiding manual version changes is part of the requirement.
    
*   The client is maintained and tested as Salesforce releases change.
    

I would consider keeping a numeric version when:

*   The integration has been tested against a specific API version.
    
*   API-version changes should be deliberate and regression-tested.
    
*   Explicit version selection is important to the integration’s release process.
    

These are development considerations, not Salesforce restrictions. Both URI styles are supported.

## `latest` Does Not Make the REST API Versionless

This is the misconception I would avoid.

With:

```javascript
/services/data/v68.0/...
```

the client specifies the API version.

With:

```javascript
/services/data/latest/...
```

Salesforce resolves the request to the most recently released API version supported by the org.

An API version still applies in both cases. `latest` simply changes how that version is selected.

## What About Retired API Versions?

Salesforce supports API versions for a minimum of three years from their first release and can later deprecate and retire older versions.

For REST API, Salesforce documents that requesting a resource or operation from a retired API version returns:

```javascript
410 GONE
```

A fixed-version integration therefore needs to account for Salesforce’s API lifecycle and move away from versions before they are retired.

`latest` addresses a different problem: it avoids hardcoding a particular numeric version by resolving to the most recently released API version.

I wouldn’t treat that as a reason to automatically migrate every integration to `latest`. Avoiding retired versions and controlling when an integration adopts a newer API version are separate architectural decisions.

## My Take as a Salesforce Developer

For me, the interesting part of `latest` is where the version decision lives.

With a numbered URI, the consuming application explicitly selects the API version.

With `latest`, the application delegates that selection to Salesforce.

For internal utilities and clients intentionally designed to follow the current REST API, that can be useful. For a business-critical integration with a controlled release process, I would first ask:

> Do we want the REST API version used by this integration to advance without changing the client URI?

That question is more useful than assuming either `latest` or a fixed version should be the default everywhere.

## Quick Reference

| Area | Details |
| --- | --- |
| Salesforce release | Winter ’27 |
| Winter ’27 API version | 68.0 |
| New alias | `latest` |
| Example | `/services/data/latest/sobjects/Account` |
| Resolution | Most recently released API version supported by the org |
| Numeric versions | Still supported |
| Setup | No separate enablement documented |
| Versions resource | `/services/data/` |

## Conclusion

Winter ’27 adds a simple but meaningful REST API versioning option: use a numbered version when the client should control version selection, or use `latest` when the client should follow the most recently released API version supported by the target org.

Before replacing hardcoded versions, decide which behavior the integration actually requires.

Would you use `latest` in a production Salesforce integration, or keep business-critical integrations pinned to an explicit API version?

## References

*   [Salesforce Winter ’27 Release Notes — Simplify REST API Version Management](https://help.salesforce.com/s/articleView?id=release-notes.rn_api_rest_latest.htm&release=264&type=5)
    
*   [Salesforce REST API Developer Guide — Introduction to REST API](https://developer.salesforce.com/docs/platform/api-rest/guide/intro-rest.html)