How to call fal models from your code
Choose a fal model endpoint, send a queued request from your server, and keep the inputs and accepted output together for the next run.
Updated 5 min read
To call the fal AI API, choose a hosted model, put your API key in the server’s FAL_KEY environment variable, and send the model’s inputs through an official client. Start with subscribe when you want the client to wait for a queued job, as described in fal’s quick start (opens in a new tab). Keep the successful request alongside the output; fenbs can hold the non-secret findings so another assistant can continue the work.
What should you choose before writing the request?
Start with one output you can check: an image for a draft page, a short video shot, or another clearly described media result. Write down what makes it acceptable before running anything. A request that completes successfully still needs a person to check whether the result does the intended job.
Choose the model ID and read that endpoint’s input schema, meaning its list of accepted fields and required values. fal’s client guide (opens in a new tab) explains that clients call a chosen model with its inputs. Do not treat one endpoint’s example as the input format for every other model.
- Record the exact endpoint you intend to call, rather than a general family name.
- Copy the required fields from its current documentation and add optional settings only when needed.
- Use a harmless test input whose output you can review quickly.
- Decide what you will save if the result passes review, including the original input and the accepted file.
For broader setup choices, use the AI connections topic. If your job is a language or multimodal request to Google instead, the Gemini API guide owns that separate workflow.
How do you install the client and protect the key?
- Create an API key from
/dashboard/keysin your fal account, following the quick start linked above. - For Python, install
fal-client. For JavaScript or TypeScript, install@fal-ai/client. - Set
FAL_KEYin the environment where your server-side script or application runs. - Keep the key out of source files, example requests you share, browser code, and the record of your experiment.
The client setup guide documents a server proxy for browser applications: your own server attaches the credential before forwarding the request. A browser bundle is the wrong place for the key because visitors can read its code. For your first experiment, a server-side script keeps that boundary easier to inspect.
Keep instructions about where configuration belongs separate from the credential itself. Our API key setup guide covers that distinction. A useful saved note says which environment needs configuration and who maintains it; it does not contain a working secret.
How do you make the first queued call?
Use the endpoint and input dictionary you checked above. This Python outline shows the call shape, with your own variables standing in for the selected model and its inputs. It deliberately avoids guessing an endpoint or assuming every model accepts the same prompt fields.
import fal_client
# Set these from your chosen model’s documented schema.
# model_id = ...
# model_inputs = ...
result = fal_client.subscribe(
model_id,
arguments=model_inputs,
)
print(result)Inspect the returned object before writing extraction logic. Match your code to the selected endpoint’s documented output instead of assuming every response has an image URL in the same place. Then save the returned data and download the output you intend to review to your chosen storage.
Keep this first call deliberately small. Avoid building batch submission, delivery, and automatic retries around an unreviewed request. Establish that the chosen inputs produce a useful result, then add the application behavior you actually need.
When should you use subscribe, submit, or run?
The documented methods serve different ways of waiting for work. subscribe follows the queue and waits for completion; submit gives you a request to track; run is synchronous, meaning the call waits directly for its response. Use the client setup reference (opens in a new tab) when choosing the method for your application.
| Method | A useful starting situation | Your record should say |
|---|---|---|
| subscribe | A script should wait for a queued generation. | The inputs, outcome, and accepted file. |
| submit | The application needs to keep track of a request separately. | Which request is still outstanding and where to resume tracking. |
| run | A synchronous call fits the intended interaction. | Which result completed and whether it passed review. |
Calling a hosted Model API is also separate from deploying your own application through fal Serverless. Do not add deployment work to a simple model-call task. In fenbs, keep the chosen method and the reason with the work so the next assistant understands the current starting point.
What should you check when a request fails?
Check one layer at a time: server configuration, the exact model ID, the required inputs, and the returned result. Confirm the server process can read its environment without printing the key. Then compare your request with the chosen model’s documented schema rather than changing several fields at once.
Keep a failed attempt separate from an accepted result. Write down which input changed, what happened, and what remains unknown. For example, “the request completed, but the output needs a different crop” is a different finding from “the request never completed.” That distinction determines the next useful action.
When a model or input changes, rerun the review against the original acceptance criteria. Retaining the request helps you explain the result; it is not a promise that a later generation will be identical. Save what you observed instead of upgrading a single good result into a general quality claim.
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
How to keep tested fal requests with fenbs
Keep enough to carry on from exactly where you left off, on another device or with another AI. The useful record is the accepted request, where its output lives, why you chose it, and the next thing to check.
- Create a free account.
- Add a task for the media result you need. Save the model ID, non-secret inputs, and a link to the output you reviewed.
- Connect your supported AI assistant to fenbs from the integrations page. Ask it to read the saved work before changing the request.
- Save what passed, what failed, and where to start next before ending the session. Keep API keys in your server configuration.
fenbs keeps the work record; it does not host the model or execute this API call. If you only need to run a one-off script and already have a clear record, your existing files may be enough. If you want media generation through an assistant instead, follow the separate fal MCP connection guide.