FlutterFlow OpenAI integration: the 2026 guide (now that the Assistants API is retiring). July 29, 2026 Fully rewritten July 2026. The original version of this post - one of the most-read guides on its 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 its 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. Infiniteup build AI features into FlutterFlow apps for clients every month - chat concierges, nutrition engines, document analysis - so this is the decision Infiniteup 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 its 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 its 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 Infiniteup consider non-negotiable, and the reason Infiniteup'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 Infiniteup 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. Infiniteup has 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 Infiniteup do - see how Infiniteup approach app development for founders, or custom AI systems for operating businesses. Turning an idea into a product? See its MVP app development approach

Campus: one canvas for humans and AI agents. FlutterFlow launched Campus on July 15, 2026, a macOS workspace that puts your repo, terminals, and AI coding agents on one infinite, persistent canvas. FlutterFlow launched Campus on July 15, 2026, a macOS workspace that puts your repo, terminals, project notes, and AI coding agents on one infinite, persistent canvas. Instead of juggling a code editor, a terminal, Slack threads, and a separate AI chat, Campus makes agents like Claude and Codex peers that see the same canvas you do and arrange tiles around you as they work. It debuted at number three on Product Hunt with more than 430 upvotes, and it is free. What this enables. Campus treats every tool as a draggable tile on a zoomable surface that remembers its layout across restarts. You talk to an agent in a real terminal tile, and it answers on the canvas by spawning, moving, and updating tiles through actual campus commands. Point an agent such as Claude Code or the Codex CLI at your repo, and its output, files, and running processes stay pinned in one spatial workspace rather than scrolling out of a chat window. Share a link and a teammate joins the same canvas with live cursors, and agents join through the same mechanism. Why it matters for creators. The hard part of building with AI agents is not the model, it is keeping context in one place. Campus is a bet that a persistent spatial canvas beats a stack of disconnected chat sessions, and it competes with the recent wave of agent workbenches such as Juggler's visual workbench for AI coding agents. For builders running multiple agents at once, having every terminal, repo, and agent action visible on one surface is a real workflow shift. Key details. Platform: macOS only, distributed as a direct DMG download. Agents: Claude and Codex act as peers, not chat boxes, driving tiles through campus commands. Collaboration: Shareable canvases with live cursors and cursor chat for humans and agents. Extensibility: A full Dart SDK reaches every layer for custom tiles and commands, from the team behind FlutterFlow. Price: Free at launch. What to do next. If you work on a Mac and already run coding agents, download Campus and move one active project onto the canvas: pin your repo, open a terminal tile, and let an agent spawn its own tiles as it works. It is the fastest way to feel whether a spatial workspace fits how you build.