How to document FLUX work for client delivery

The FLUX models from Black Forest Labs, from FLUX1.1 pro to FLUX.2, reach production mostly through the API: a pipeline or a product submits a request, receives a request id and a polling URL, and polls until the result arrives as a signed URL in the sample field. That URL is the delivery. Black Forest Labs states that its signed URLs are only valid for ten minutes and asks integrators to retrieve results within that window, and it recommends downloading the image and serving it from your own infrastructure rather than passing the link along.

For documentation this inverts the usual situation. Hosted creative tools keep an archive you do not control, while FLUX keeps, as far as the documentation describes, nothing you can browse. There is no session view, no organize page, and no history to consult when a client asks how an image was made. Whatever your integration writes down at request time is the record, and whatever it does not write down never existed. The API cooperates with this discipline better than most tools: requests are plain JSON, the FLUX1.1 pro endpoint documents an optional seed for reproducible results that accepts any integer, and the request id gives every generation a stable name to log under.

The teams that get this right treat logging as part of the integration rather than an afterthought. One log entry per request, written before the call returns, holding the full request body and the id, and completed within the ten minute window with the downloaded file and its hash. Built on day one, that is a small amount of code. Retrofitted after a client dispute, it is impossible, because the material is gone.

What FLUX stores on its side

• A generation request returns a request id and a polling URL, and the finished image arrives as a signed URL in the result's sample field. Source
• Black Forest Labs states that its signed URLs are only valid for ten minutes and that results must be retrieved within this timeframe. Source
• The documentation recommends downloading the image and re-serving it from your own infrastructure rather than serving the delivery URLs directly to users. Source
• The FLUX1.1 pro endpoint documents an optional seed parameter for reproducible results that accepts any integer. Source

What gets lost without your own record

• Ten minutes after the result is ready, the delivery URL is dead. A pipeline that logged the request id but never downloaded the file has a receipt for an image it can no longer produce.
• The documentation describes no browsable history or archive, so there is no account page to consult later and no vendor to ask for a copy.
• The downloaded image is a plain file, and nothing connects it to its prompt, seed, or endpoint except the log your own system keeps.
• A request submitted without an explicit seed cannot be reconstructed from the request alone, because the randomness was resolved on the server in a call you cannot replay.

The documentation checklist for FLUX

1. Log the full request body at submission time, including the prompt, dimensions, and every parameter, keyed by the returned request id.
2. Set an explicit seed on production requests, so the request log alone is enough to regenerate the image on the same endpoint.
3. Download the result inside the ten minute window, store it in your own storage, and record a content hash next to the log entry.
4. Record the exact endpoint and model that generated the image, for example FLUX1.1 pro or FLUX.2, together with the request date.
5. Store any input or reference images the request included, because the API holds nothing for you.
6. Link the stored image to the client, the project, and the approval in your own system, since the API has no concept of any of them.

An API-first tool moves the entire documentation burden to the integrator, and that is more of a gift than it sounds. Nothing is hidden in a vendor account, nothing expires except the ten minute delivery link, and the record can be exactly as complete as the code that writes it. A FLUX pipeline with request logging, explicit seeds, and immediate downloads produces a cleaner evidence trail than most browser-based tools, because every field was captured by a machine at the moment it was true.

The same record carries the compliance weight. Images generated through FLUX and published in the EU fall under the transparency obligations of Article 50 of the EU AI Act, with penalties for transparency violations of up to €15 million or 3% of worldwide turnover, and a headless API will not disclose anything on your behalf. A log that ties each published image to its request, its download, and its approval date is what lets the team that ships the work answer for it.

Frequently asked questions