Connector forms for image.generate and image.edit
Both job types picked their model from a union, which the connector field projection could not represent, so n8n and every other connector showed an empty panel and a raw JSON box. They now render a model dropdown plus that model's own fields.
image.generate and image.edit declare their parameters as one branch per model, because a model’s options are not the same as its neighbour’s. The projection behind GET /jobs/types/{type}/schema only understood flat objects, so both types came back with no fields at all. Connectors fell through to a raw JSON textarea, and you had to read the docs to learn what a model accepted.
Both now return a proper form. image.generate returns 12 fields: a model dropdown listing all nine models, five that apply to every model, and the rest gated to the models that accept them. image.edit returns 10 the same way.
The gating matters more than the count. steps is 4 to 8 on qwen-image-2512-lightning, 10 to 50 on flux-2-dev and 20 to 50 on qwen-image-2512. Merging those into one field would give most models a range the API rejects, so each keeps its own, and a field is never offered for a model that would refuse it.
- Fields carry a
showWhencondition naming the model or models they belong to. - The response carries a
discriminatornaming the field that selects the branch. - Every JSON-shaped parameter now has a description and a worked example. Four of them had no description at all, including
styleoncaptions.animateandvideo,audioandtuningoncompress.target.
Nothing changed about what the API accepts. This is the discovery contract catching up with what the job types already supported, so a connector that ignores the new keys keeps working unchanged.
compose still returns no fields, which is deliberate. Its timeline is recursive and has no discriminator, so it stays a JSON field with an example.
See job types for the endpoint, and image.generate and image.edit for what the two job types do.