How to call the FLUX API and keep reproducible requests
Create a BFL key, submit an image request, follow its polling URL, and save the finished file with the recipe that produced it.
Updated 5 min read
To call the FLUX AI API, create a project key in the BFL dashboard, submit a request for your chosen model, and poll the returned polling_url until the image is ready. Download the finished image and keep the request separately; BFL’s delivery link is temporary. The BFL integration guide (opens in a new tab) documents that sequence. fenbs can keep the useful findings and next step outside the code or chat where you ran the test.
Where do you create the API key?
BFL’s Quick Start (opens in a new tab) places direct API credentials at dashboard.bfl.ai: open the project sidebar, choose API, then Keys, then Add Key. A key belongs to that project and is shown once. Direct API usage requires a BFL account with credits, so check the account before treating a failed submission as a prompt problem.
Keep the credential out of prompts, screenshots, shared request examples, and saved work notes. Your reusable recipe needs the model and nonsecret settings, not the credential that authorizes a call. Our API key setup guide explains that separation for someone making their first connection.
Before running anything, choose a small test you can judge. For example, use an image brief for an unbranded ceramic cup on a plain surface. Decide what counts as success, such as a visible handle and enough empty space for a headline. That gives the first request a purpose beyond merely producing a file.
How do you submit and poll an image job?
- Select the model and use its current vendor request example. Keep the endpoint, model identifier, prompt, and nonsecret parameters together before sending the request.
- For the documented image-editing example, POST to
https://api.bfl.ai/v1/flux-kontext-prowith bothpromptandinput_image. Supply an image you are authorized to use. - Read the returned
polling_urlfrom the submission response. Save the job information with your local test record so you can identify this request. - Poll that returned URL for the result. When the status is
Ready, read the image address fromresult.sample. - Download the image into storage you control, then inspect it against the test brief before marking the test successful.
The endpoint above comes from BFL’s Kontext editing instructions (opens in a new tab). Those instructions describe Kontext as a previous-generation option and recommend FLUX.2 for new editing work. Use the request sample for the model you actually select; this example is not a universal payload for every FLUX model.
Follow the returned polling URL on both global and regional API calls. BFL explicitly tells developers to use it rather than constructing a result endpoint. Keep submission and result collection as separate stages in your own program, so an accepted request is not accidentally reported as a finished image.
A reader coming from our Gemini API introduction should pay particular attention to that separation. Keep the general habit of a small test and a saved request, but use BFL’s own model example and asynchronous result flow for this integration.
What needs to happen before the delivery link expires?
Treat the result address as a delivery step. BFL says these URLs expire and are not intended for direct end-user serving; the integration guide also warns about cross-origin browser access. Fetch the image bytes into your own storage and use your own stored copy when the asset must remain available.
Give the saved file a name that connects it to the request record, such as cup-background-test-a. Open that file after downloading it. A successful status and a copied URL do not prove you have a readable image saved where the next person can find it.
Separate a usable download from an approved design. You might save three successful responses while approving only one composition. Record which file passed review and why. A later assistant should be able to tell whether a file is merely an experiment or the version someone agreed to use.
Which request details make the test repeatable?
Save the request you sent, rather than a cleaned-up description written afterward. Retain the model identifier, endpoint, prompt, dimensions and other settings you supplied. Where your chosen model exposes a seed, record its actual value; otherwise mark it as not recorded rather than inventing one.
| Keep | Why it helps |
|---|---|
| Exact model and endpoint | Identifies the generation path used for this test. |
| Prompt and supplied settings | Shows what was actually submitted before later edits. |
| Original input images | Lets a reviewer identify the references used. |
| Saved output location | Finds the downloaded file after temporary delivery ends. |
| Review and next test | Explains what worked and what should change next. |
A request recipe supports a controlled comparison; it does not promise identical results across models or providers. Label a change of model as a new test. For the writing side of that record, use the FLUX prompt test guide rather than changing the prompt and the integration at once.
Keep the review beside the recipe in fenbs’s shared work record, so the next assistant can see the reason for a change before suggesting another request.
Never lose the work you did in an AI session
After a useful AI session, save it in fenbs: the key observations, findings, research and context. Then carry on from exactly where you left off, on any device and in any other AI. The next AI you connect reads it at the start of the session, so you never have to explain the same problem again.
Create a free accountFree for up to 5 people and 50 open tasks · No credit card · Works with Claude, ChatGPT, Cursor and more
What should you check when the workflow fails?
Find the last stage you can prove worked: credential creation, request submission, result polling, download, or image review. Record the response you received after removing secrets. This is a troubleshooting method, not a list of guaranteed BFL error messages.
- No accepted submission: compare your request with the selected model’s current vendor example and check the account and project you intended to use.
- Submission accepted but no saved image: inspect whether your code retained and used the returned polling URL.
- Image address received but file unavailable: check whether you downloaded it promptly instead of keeping only the temporary address.
- File saved but the subject is wrong: keep the integration result separate from the creative failure and revise one part of the image brief.
Before retrying, check whether the earlier request already produced a result. Repeatedly submitting new work while losing track of old work makes comparison difficult. Keep one row per attempt and write what you changed, even when the attempt failed before an image appeared.
How to keep API test findings with fenbs
Keep the recipe and the last verified step so you can carry on from exactly where you left off, on any device and in another connected AI. Leave credentials in your credential storage and image files in your chosen asset storage.
- Create a free account.
- Write what you wanted the image to show and link to the saved file you reviewed.
- Save the model name, prompt, nonsecret settings, and the short finding from that test.
- Write the next step before you stop, such as checking the cup handle on a second composition.
- Ask your next connected assistant to read that record before suggesting a new request.
fenbs does not run the FLUX API or store your image files for this workflow. If you only need a one-off download, saving the file and request locally may be enough. The AI connection guides cover the wider setup, while a lasting record becomes useful when several sessions need to continue the same test.