How to document FLUX work for client delivery

This checklist focuses on direct BFL API image generation. A request returns an id and polling URL; a completed result provides a signed download URL in the sample field. Black Forest Labs gives these URLs ten minutes of validity and recommends downloading results to your own infrastructure. That delivery-link limit does not describe every FLUX product's storage or history.

BFL also offers a browser Playground for generating, iterating and downloading. Its help center documents an API Code control that copies a successful generation's exact parameters. For Playground work, retain that information when useful and check the relevant export and retention options. Third-party FLUX products have their own account and storage behavior.

In an API integration, create a local log entry when submitting the request, add the returned id and polling URL, and attach the downloaded image when ready. Retain the request body, endpoint, model and input files alongside the output. This makes the production context available for your team without depending on a temporary delivery URL.

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
• The BFL Playground supports browser generation, iteration and downloads, and its API Code control provides a successful generation's exact parameters. Source
• BFL distinguishes preview endpoints that track model updates from non-preview endpoints intended for pinned-model reproducibility. Source

What gets lost without your own record

• The API's signed delivery URL expires after ten minutes. A saved request id is not a durable copy of the image, so confirm the download succeeded.
• The API delivery instructions do not establish Playground retention or third-party history. Check the surface you actually used before concluding that an older result is recoverable or lost.
• A downloaded image alone is not your request log. Keep an explicit connection to the prompt, seed, endpoint and inputs rather than assuming you can recover those fields from the file.
• A seed supports reproducibility, but the model and other request settings matter too. A rerun should not replace the archived, approved output.

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. Record an explicit seed where supported and keep the other generation settings. Use a suitable pinned endpoint when reproducibility matters, and preserve the original output.
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 the input or reference images used in the request and link them to the corresponding output.
6. Link the stored image to the client, project and approval in your production record.
7. For BFL Playground work, capture relevant parameters with API Code and check available downloads; for a third-party product, check its own history and export controls.

Behind The Workflow gives this FLUX record a practical home: keep an asset with the prompt, model, references, versions and decisions your team adds. Upload or explicitly capture the available details, fill the gaps, and review the record before handoff. BTW does not automatically reconstruct an external generation history or verify reference rights.

Request logging is a useful part of an API workflow because it captures what your integration submitted. It becomes a delivery record when you connect that request to the file you retained and the decision to use it. Verify that connection, including failed downloads or retried requests, instead of treating a log entry as proof that the intended file was archived.

The same record helps with disclosure decisions without turning every FLUX image into the same legal case. Article 50(2) addresses provider-side machine-readable marking. Article 50(4) gives the deployer a disclosure duty when a published image constitutes a deep fake. A headless API does not make that publication decision, so a log that ties each final image to its request, download, classification, disclosure and approval date gives the team useful evidence of what it did.

Frequently asked questions