generation API multiple reference images: Account for the first-reference mapping

The generation API multiple reference images contract has a clear limit in the current adapter implementation: the ordinary upstream mapping uses only imageInputs[0]. The schema accepts an array, but acceptance of several URL entries does not establish that all entries reach the model or contribute to the output.

Inspect the mapping rather than the shape

The image and video providers conditionally add image_url using the first array entry. They do not iterate through the array to create a multi-image upstream field. The extra object is spread afterward and can alter upstream input, but that escape hatch is not a documented guarantee of multi-reference blending.

This distinction matters for a user interface that accepts a product image, a style board, and a logo. If it sends those as three entries, the normal mapping forwards only the first image as image_url. Calling the result a blend of all three would misrepresent the submitted evidence.

Choose one primary reference deliberately. Label other uploaded assets as local briefing material unless your application has a separately verified processing step that actually uses them.

Make ordering reviewable

When the user selects a primary source, store its asset identifier, content hash, and position. Keep the serialized order stable through drag-and-drop changes, draft restoration, and upload completion. A late upload should not silently move ahead of the approved source.

An example review record can say that the front-view product photograph is the submitted reference and the side-view image is available only to the human reviewer. This is more informative than storing an unlabeled collection and assuming every file influenced generation.

If your workflow needs several views, a possible application design is separate requests with one chosen reference per request, followed by a manual comparison. Each submission is separate work with its own job and potential cost. Do not describe that design as automatic multi-image fusion.

Guard against false fidelity conclusions

A reviewer may notice that an output resembles a secondary reference by chance or through prompt description. That observation does not prove the secondary image was transmitted. Establish the actual request first, then evaluate the output against the intended source.

For sensitive product details, retain the original asset and compare key geometry, labels, and distinguishing features. A reference-assisted request does not guarantee exact reproduction. If exact branding matters, use a deterministic downstream composition step with approved source artwork.

Offline acceptance

Create a two-image fixture with unmistakably different URLs. Inspect the adapter’s expected upstream object and verify that image_url equals the first entry. Test reordering and confirm that the expected source changes visibly in the review.

Approve the interface when it identifies the submitted reference, explains the unused attachments, and preserves source provenance. Read empty reference arrays, reference fidelity review, and output storage to complete the evidence chain.

Continue with models and parameters

• Flux API key: two paths, and what changes after you have one
• Flux API parameters: every accepted value and what it costs
• Flux aspect ratio options: what it accepts and what it rejects
• Browse all models and parameters guides