Versioning Lifecycle
Every Atoms agent’s runtime config (prompt, tools, voice, language, post-call metrics) is managed as revisions on branches. You edit a branch as a draft, publish the draft as a new revision, and make the branch you want live. This guide walks the full lifecycle from code.
For the dashboard equivalent and a deeper conceptual overview, see Agent Versioning. For an endpoint-by-endpoint mapping from the v1 API, see the v1 to v2 migration guide.
All examples assume BASE="https://api.smallest.ai/atoms/v1" and SMALLEST_API_KEY is set in your environment.
The flow
A few points worth internalizing before you touch the API:
- Every agent starts with a
Mainbranch, andMainis live on day one.Main’sVersion 1is the config the agent serves. - Edits on any branch stack up as a single draft on that branch. You call
PUT .../draftas many times as you want; each call merges into the same open draft. - Optimistic concurrency: pass
expectedRevision: <draftRevision>onPUT .../draftto get a field-level conflict check. If another edit changed the same leaf field since, the server returns409with aDraftConflictErrorbody listing the conflicting paths. OmitexpectedRevisionfor last-write-wins. - Publish commits the draft as a revision. Revisions are immutable.
- Every publish runs a security scan. If the draft already passed (a re-publish) or the workflow type is non-scannable, the commit happens synchronously and you get
200withstate: "committed". Otherwise the scan is armed and you get202withstate: "scanning"; commit happens on scan pass. AFAILEDdraft is rejected with409(edit and re-publish). - Publishing on the live branch pushes to production immediately. Publish on a non-live branch first if you want to stage.
- Restore does not touch the draft slot. It takes an older revision’s config and publishes it as a new revision at the head of the branch. So a branch with
v1, v2, v3restored tov1ends up withv1, v2, v3, v4, wherev4’s content matchesv1andv4is the head. If the source revision’s security check failed or errored, restore is rejected with403. - Test-call target: send
includeDraft: trueto test the open draft,revisionIdto test a specific committed revision, or omit both to test the branch’s committed head.
Full walkthrough (curl)
Python walkthrough
Two ways to run the same lifecycle from Python: use the smallestai SDK (typed methods + a Versioning helper that wraps the publish-and-poll dance), or call the REST endpoints directly with requests.
Python (SDK)
Python (requests)
Source of truth: examples/agent_versioning_lifecycle.py in the SDK repo.
Working with additional branches
Fork a branch when you want to stage a big change without touching production. The source branch must have at least one committed revision.
Reverting
Restore republishes an older revision as a new revision at the head of the branch. If the branch is live, traffic switches immediately.
Migrating from the v1 versioning API
If your integration calls /agent/{id}/drafts/* or /agent/{id}/versions/*, those are the v1 versioning endpoints. Move to the branch-and-revision endpoints:
Existing versionId values continue to resolve as revisionId, so IDs stored by earlier integrations keep working. Full endpoint-by-endpoint mapping and 409-handling patterns live in the v1 → v2 migration guide.

