An operation’s address is its name
Every path is the operation name with its dots turned into slashes. email.send is /email/send, auth.signin.start is /auth/signin/start, sms.number.release is /sms/number/release. One rule, no exceptions, which is what lets an agent work out an address instead of looking it up.
There is no version segment. The version used to be in every URL a customer saw — the guides, the examples, the OpenAPI document, the Try It button — and a version number is a promise about the future made in the most public place there is. It was taken out of everything anyone reads.
/v1 still answers, and always will
Every operation is mounted twice: at its canonical path and under /v1. Anything already written against /v1/email/send keeps working, unchanged, with no cutover and no window where a caller breaks. Only what people read changed.
The routes are registered from one list rather than twice by hand, so an operation cannot end up served on one address and not the other — a failure that would look like the docs being wrong from outside and be invisible from inside.
A handful of /v1 addresses are not that scheme at all. /v1/callbacks/email, /v1/sms/status, /v1/sms/inbound and /v1/inbound/ingest are URLs configured inside AWS and the carrier’s console, not URLs a customer calls, and they stay where they are because rewriting them would break live traffic to buy nothing. They are left out of the published reference for the same reason.
What is not built yet
There is no Lath-Version header, no version query parameter and no per-account pinning. Nothing negotiates a version, so nothing can pin one.
There is no deprecation policy either — no sunset header, no advance-notice window written down anywhere. Saying so plainly is more useful than a policy page nobody has committed to: when one exists it will be written here, and until then the honest answer is that the only compatibility promise Lath makes is the one above, that an address which works keeps working.
What changes without warning, and what does not
Operations are added. Fields are added to results. Neither is announced, so parse results leniently: read the fields you need and ignore the ones you do not, and do not assert on an exact object shape.
Every input is strict — an unknown field is refused rather than ignored, which is how a typo in a field name is a refusal today instead of a silently dropped value discovered in production.
The operation catalogue is generated, so the reference, the OpenAPI document, the SDK types and the CLI commands are the same list. If an operation is in one it is in all of them.Last modified on September 16, 2026
