Every Salesforce integration carries a version number baked into its URIs — /services/data/v66.0/... — and every release, someone has to decide whether to bump it. Winter ‘27 adds a small convenience for the cases where you’d rather not track that at all: you can write latest in place of the version number.
https://<MyDomainName>.my.salesforce.com/services/data/latest/sobjects/AccountInstead of the pinned form:
https://<MyDomainName>.my.salesforce.com/services/data/v66.0/sobjects/AccountRequests to the latest path route to the most recent REST API version your org supports. That’s the whole feature — and its usefulness depends entirely on the context you use it in.
Where it helps
For internal scripts, prototypes, local tooling, and one-off exploratory calls, latest removes a genuine chore. You always hit the newest version, and if something shifts, the cost is low because the caller isn’t a production dependency. This is the intended sweet spot: convenience for work where being current matters more than being stable.
Where to keep pinning
For a production integration, “automatically moves to a new API version every release” is a behaviour to think twice about. A version bump can bring schema changes, altered defaults, or subtly different responses — and with latest, that arrives without a deploy, a review, or a changelog entry on your side. The safer pattern for anything a business depends on is to pin an explicit version and upgrade deliberately, testing against the new version before you move.
That’s the same discipline that shows up whenever you choose a Salesforce integration pattern: the convenient default and the resilient default aren’t always the same one. latest is a good tool for the low-stakes majority of calls and a poor default for the calls that page someone at 2am.
What it doesn’t touch
latest only changes which version the URI resolves to. Authentication, headers, and request and response formats behave exactly as they would for that resolved version — the same care around error handling and retries covered in building resilient Salesforce integrations still applies. It removes a maintenance chore, nothing more, which is precisely why it’s worth using in the right place and avoiding in the wrong one.