API versioning is the practice of labeling distinct, non-interchangeable versions of an API so consumers can keep using an older contract while a provider evolves the API without breaking them.
Common schemes include versioning in the URL path (/v1/users, /v2/users), in a request header, or in the request payload itself. Whichever mechanism is used, the point is the same: a breaking change — renaming a field, changing a response shape, removing an endpoint — gets shipped as a new version rather than silently altering the behavior existing integrations depend on.
Good versioning discipline draws a hard line between breaking and non-breaking changes: adding a new optional field is safe to ship into an existing version, but removing a field, changing its type, or altering required parameters is not — that needs a new version, with the old one supported for a defined deprecation window. Skipping this distinction is how a "minor update" quietly breaks every integration overnight.
Versioning is also the mechanism that makes deprecation possible in a controlled way — without distinct versions, a provider has no way to retire an old behavior for some consumers while keeping it running for others still mid-migration.
Neotask's internal automation API is explicitly versioned so the Electron desktop app and the web client — which don't always ship on the same release cadence — can each keep working against the version they were built for while the backend evolves underneath them.
$0/mo
Download without a card and start for free.
$50/mo
The full personal agent platform for one person.
$100/mo
One company workspace with room to add your team.
$200/mo
Multiple workspaces and capacity for larger teams.
Explore: Integrations · Skills · Solutions · Use cases · Examples · Comparisons · Templates · Blog · Docs