Saving a version
Save a new version.
POST /projects/{id}/versions is the headless equivalent of the platform's "Save project": it commits an updated vendor file as a new version of an existing project. Requires code_write.
Contract
- Body is
{ originalFilename, file: { inline | blob_url } }. Files up to ~4.5 MB may go inline as base64; larger ones upload to a blob URL your integration controls and passblob_urlinstead. The SDKs pick the path for you by size. - The file must be the same vendor as the project (an L5X stays L5X, a Siemens ZIP stays Siemens). A mismatch returns
400. - Re-sending the exact bytes of the current version is a no-op:
200withresolution: identical_fileand no new version. - A real commit returns
201and bumps the project's current version. Graph and search indexing follow automatically; analysis does not.
res = client.commit_version("prj_…", file_path="Conveyor_edited.L5X")
print(res.resolution) # add_version | identical_file
print(res.version_id) # the new version, or None for identical_filevar res = await client.CommitVersionAsync(
"prj_…", File.ReadAllBytes("Conveyor_edited.L5X"), "Conveyor.L5X");
Console.WriteLine(res.Resolution); // add_version | identical_file
Console.WriteLine(res.VersionId ?? "null");Committing a version does not analyse it. Saving is an edit, and analysis is expensive and per-version, so it is never a side effect of a write — the app's own editor Save behaves the same way. The project's existing analysis still describes the version it ran on, and says so: every payload carries is_current_version. Ask for a fresh run explicitly — see Analysis.
A project-scoped key may only commit to in-scope projects, and can never create a new project identity — onboarding a machine happens in the app or through a version-source connector, not here. The write requires an Idempotency-Key.