The workflow behind a job — authoring version if pinned, executed graph otherwise
Returns the workflow behind a job. The response’s format field says
which of two different shapes workflow is in:
format: save— the original authoring workflow exactly as saved in the Comfy Cloud editor at the version the job ran, including canvas layout and frontend-only nodes (e.g. Note nodes; Get/Set nodes not yet expanded). Returned only when the job is pinned to a specific workflow version — see the “when you get which” note below.format: api— the executed API-format prompt graph the job actually ran: frontend-only constructs are gone and Get/Set nodes are expanded. This is the same shapePOST /api/v2/jobs’sworkflowrequest field takes, and never includes the submission’sextra_data, which can carry a live credential.
Always branch on format, never assume one or the other — which
shape comes back depends on how the job was submitted, not on
anything the caller controls per-request.
A deliberate sub-resource, not a field on GET /api/v2/jobs/{id} —
so the polling workhorse stays cheap and a caller pays for this only
when it actually wants the workflow (for example, to recover what
produced a given output).
Tied to the job’s own retention: this 404s under the same conditions
GET /api/v2/jobs/{id} does (unknown, not-yours, or past its
retention deadline) — there is no separate lifetime for the
workflow.
When you get which: a job only carries a pinned workflow version
when it was submitted with that association. Today that means jobs
submitted from the Comfy Cloud frontend/editor. Jobs submitted
directly through this v2 API (POST /api/v2/jobs) do not carry that
association — v2 job submission has no version-linking fields yet —
so they always get format: api. This is expected, not a bug: it
will change once v2 submission grows the same version pinning.
A job pinned to a version also falls back to format: api if that
version, or the workflow it belongs to, is no longer readable by the
caller — for example the caller deleted the workflow since the job
ran. This is the same fallback as an unpinned job, and for the same
reason: it is preferable to the alternative of erroring the whole
request over data that is genuinely gone.
授权
Authorization: Bearer <api-key> — account-scoped API keys on Cloud and serverless. Self-hosted accepts unauthenticated requests by default and can be configured with a static bearer token.
路径参数
响应
The workflow graph.
The workflow behind a job. See GET /api/v2/jobs/{id}/workflow's description for exactly when format is save vs api.