Why versions matter
Your code calls a deployment, not a workflow. Editing your graph in ComfyUI changes nothing about what your API calls do until you deploy the new version. That’s the safety property worth internalizing:- Experiment freely — production keeps running the deployed version
- Ship deliberately — deploying is the moment behavior changes
- Roll back by pointing at the previous version
Inputs are a contract
Your graph’s input nodes define what callers must send. Theinputs object in a run request maps to those names:
- Adding an optional input is safe
- Renaming one breaks existing callers
- Removing one breaks existing callers
- Changing the type breaks them quietly, which is worse
Inspecting a version
GET /workflow-version/{version_id} returns a version’s detail — useful when a run behaved unexpectedly and you want to confirm which revision actually executed. Every run records its workflow_version_id, so you can always trace a result back to the exact graph that produced it.
Machines
Runs execute on a machine, recorded asmachine_id on the run. Two runs of the same deployment on different machines should behave identically — if they don’t, the machine is where to look, and the machine_id is what to report.
Run origin
Every run records where it came from:
Useful for separating your own testing from real traffic when you’re reviewing history.
Practical workflow
1
Build and test by hand
Get the graph right in ComfyUI first. Debugging a graph through API calls is slow.
2
Name your inputs deliberately
They’re a contract.
input_image beats image2.3
Deploy
Note the
deployment_id. That’s what your code stores.4
Call it once by hand
Confirm one run end to end before wiring it into anything.
5
Version forward
For breaking changes, deploy alongside and migrate — don’t mutate what’s live.
