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 shape POST /api/v2/jobs's workflow request field takes, and never includes the submission's extra_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.