Fully rewritten July 2026. The original version of this post — one of the most-read guides on our blog — walked through integrating OpenAI’s Assistants API into FlutterFlow. OpenAI is shutting that API down on August 26, 2026. This rewrite covers what to use instead, and how to migrate if you built on our original guide.
There are now three good ways to run a FlutterFlow OpenAI integration, and the right one depends on how much control you need. We build AI features into FlutterFlow apps for clients every month — chat concierges, nutrition engines, document analysis — so this is the decision we make repeatedly, not a summary of someone else’s tutorial.
First, the deadline: the Assistants API is going away
If your app still calls the Assistants API — threads, runs, run steps — it stops working on August 26, 2026. OpenAI has said there will be no extension, and no automated tool to migrate your stored threads. Its replacement is two simpler building blocks: the Responses API (send input, get output) and the Conversations API (stores the back-and-forth). The mapping is mercifully clean:
- Assistants → Prompts. Your assistant’s configuration (model, tools, instructions) becomes a Prompt, managed in the OpenAI dashboard rather than created over the API.
- Threads → Conversations. A conversation object holds the running history, including tool calls — not just messages.
- Runs → Responses. One request, one response. The polling loop our 2023 guide taught you — create a run, then check its status until it completes — is gone entirely, and good riddance.
- Run steps → Items. Messages, tool calls and outputs are all just items in the conversation.
If you need your users’ existing thread history, you have to move it yourself before the shutdown: fetch the messages from each thread and write them into a new conversation. Budget a day for it. If your chat history is disposable, skip the backfill and start clean.
Option 1: FlutterFlow’s built-in AI Agents (start here)
FlutterFlow now ships first-class AI Agents, and for most apps this is the right starting point. You define the agent inside FlutterFlow — provider (OpenAI, Google, Anthropic or ElevenLabs), system message, example conversations, temperature, response format — and the platform handles the plumbing.
The part that matters most is what it does with your API key. When you use an OpenAI agent, FlutterFlow deploys a Cloud Function in your Firebase project that relays requests to the API, so the key lives on the server and never ships inside your app. That requires your Firebase project to be on the paid Blaze plan — a common stumbling block, so upgrade before you wonder why deployment fails.
In your pages you then use the agent actions: Send Message (with a conversation ID, so context carries across turns), Clear Chat History, plus speech, transcription and image generation if you’ve configured those agent types. Chat agents accept text, images and documents depending on the provider, and can return plain text, markdown or JSON.
The honest limitation: agents are controlled workflows, not autonomous ones. There’s no function calling, so the model can’t trigger your app’s actions or query your database mid-conversation. For chat, summaries, suggestions and guided flows, that constraint won’t bother you. The moment you need the AI to do things rather than say things, you’ve outgrown Option 1.
Option 2: the API Calls interface, pointed at the Responses API
FlutterFlow’s API Calls interface — the same one our original guide used — works fine against the new endpoints. Create an API group for OpenAI, add a POST call to /v1/responses with your model and input, and parse the output items from the JSON. For multi-turn chat, either pass previous_response_id or create a conversation object and reference it on each request; the conversation route is what OpenAI recommends now, and it spares you from rebuilding history client-side.
One rule we consider non-negotiable, and the reason we’d steer most teams to Option 1 or a proxy: do not put your OpenAI API key in a client-side API call. A key stored in app state or an API header ships inside your binary, and extracting it is trivial. Every real project we deliver routes AI calls through a backend the key lives in — a Firebase Cloud Function, a Supabase Edge Function, or the client’s existing API. The FlutterFlow side then calls your endpoint, which calls OpenAI. That’s fifteen extra minutes of setup, and it’s also where you add the things production apps need anyway: rate limiting, logging, cost caps per user, and guardrails on what the model may be asked.
Option 3: custom code, for the last 10%
Custom actions in Dart give you everything the first two can’t: token-by-token streaming so responses appear as they’re generated, retry and timeout logic tuned to your UX, and multi-step orchestration — the pattern where a request fans out to several model calls and the results are merged. We’ve used this for apps where a queue of AI jobs runs against uploaded images, and for a nutrition engine where one user action triggers a chain of structured-output calls. If you don’t already know you need this, you don’t need it yet.
Which one should you pick?
- Chat, summaries, content generation, guided Q&A → the built-in AI Agents. Least code, key handled properly by default.
- Structured outputs, your own backend, tool use, cost controls → API Calls against the Responses API, always through a server-side proxy.
- Streaming, orchestration, heavy custom logic → custom code actions, written by someone who has done it before.
And a closing note from the field: the model call is the easy fifth of any AI feature. The work that decides whether users trust it is everything around the call — what happens when the API is slow, what happens when the answer is wrong, how you keep one enthusiastic user from spending your month’s token budget in an afternoon. That’s app engineering, not prompt engineering, and it’s the difference between a demo and a product.
Building an AI feature into a FlutterFlow app and want it done right the first time? That’s a large part of what we do — see how we approach app development for founders, or custom AI systems for operating businesses.