Integrate a REST API in FlutterFlow by creating an API Group in API Manager with the base URL and authentication headers, then adding individual API Call entries for each endpoint. Use the Response and Test tab to inspect the response structure, mark the fields you need, and bind them to widgets via Backend Query or Action Flow. Always handle non-200 status codes in your Action Flow to show error states rather than blank screens.
Connect any third-party REST API to your FlutterFlow app without writing server code
FlutterFlow's API Manager lets you connect to any REST API directly from the visual builder — no backend code required for publicly accessible APIs. You define a base URL, set shared authentication headers, add individual endpoints, and bind the response data directly to widgets using Set from Variable. For APIs that require server-side secrets (OAuth client credentials, private API keys you do not want in the compiled app), route through a Cloud Function instead and call the function URL from API Manager. This tutorial walks through the complete process from reading API documentation to displaying live data in your FlutterFlow UI.
Prerequisites
- A FlutterFlow project (Firebase not required for read-only API calls)
- An API to integrate — this tutorial uses OpenWeatherMap as a concrete example, but the steps apply to any REST API
- An API key from your chosen service (most have free tiers for development)
- Familiarity with JSON format — understanding nested objects and arrays in API responses
Step-by-step guide
Read the API documentation and plan your endpoints
Read the API documentation and plan your endpoints
Before opening FlutterFlow, read the API documentation thoroughly. Identify: the base URL, authentication method (API key in header vs query param, Bearer token, Basic Auth), the specific endpoints you need, their HTTP methods (GET, POST, PUT), required parameters, and the JSON response structure. For OpenWeatherMap, the base URL is https://api.openweathermap.org/data/2.5/ and the current weather endpoint is GET /weather with query params q (city name) and appid (API key). Sketch the response fields you need: main.temp, main.humidity, weather[0].description, weather[0].icon. Knowing this before you start saves significant back-and-forth in FlutterFlow.
Expected result: You have a clear plan: base URL, auth method, endpoints, parameters, and the specific JSON fields you will bind to your UI.
Create an API Group in FlutterFlow's API Manager
Create an API Group in FlutterFlow's API Manager
In FlutterFlow, click the API Manager icon in the left sidebar (looks like a plug). Click Add API Group. Name it descriptively (e.g., WeatherAPI). Set the Base URL to https://api.openweathermap.org/data/2.5. For authentication: if the API uses a query parameter for the key (like OpenWeatherMap's appid), you will add it at the individual call level. If the API uses a header like Authorization: Bearer YOUR_TOKEN, add it here as a shared header. Store the actual key value in FlutterFlow Secrets: go to Settings → Secrets → Add Secret named WEATHER_API_KEY. Reference it in the header value field as [secretName]. Add any shared headers that apply to all endpoints (e.g., Content-Type: application/json for POST-heavy APIs).
Expected result: An API Group is created with the base URL and shared authentication configuration ready for individual endpoints to be added.
Add an API Call and test the response
Add an API Call and test the response
Inside the WeatherAPI group, click Add API Call. Name it getCurrentWeather. Set Method to GET. Set the path to /weather. Under Query Parameters, add q (city name, Variable type — will be supplied by the caller) and appid (your API key, either hardcoded if it's safe to expose, or as a Secret reference [WEATHER_API_KEY]). Click the Response & Test tab. Enter a test value for q (e.g., London). Click Test API Call. You should see the full JSON response in the panel. Expand the response tree and click the checkmark next to each field you need: main > temp, main > humidity, weather > 0 > description, weather > 0 > icon. These checked fields become available as bindable variables in your UI.
Expected result: The test returns a 200 response with real weather data. The fields you marked are available as response fields that can be bound to widgets.
Bind the API response to a page using Backend Query
Bind the API response to a page using Backend Query
On the page where you want to display the data, click the page's Properties Panel → Backend Query tab → Add Query → API Call → select WeatherAPI → getCurrentWeather. For the q parameter, bind it to a Page State variable that holds the city name (populated from a TextField). With the Backend Query set up on the page, any child widget can now access the response fields via Set from Variable. Click a Text widget → Set from Variable → Backend Query Result → getCurrentWeather → main > temp. Repeat for humidity and weather description. For the weather icon, use an Image widget → set Network Image URL to https://openweathermap.org/img/wn/{icon}@2x.png where {icon} is bound to the icon field from the response.
Expected result: The page displays live weather data for the city specified in the TextField. Changing the city and re-loading the query shows updated weather.
Handle API errors and non-200 responses in the Action Flow
Handle API errors and non-200 responses in the Action Flow
Never assume the API will always return 200. Network errors, expired keys, rate limits, and invalid inputs all produce error responses. In your Action Flow (e.g., when the user taps a Search button), after the API Call action, add a Conditional Action checking if the API response status code is not equal to 200. In the TRUE branch (error), show an Alert Dialog or Snackbar with an appropriate message: 'City not found' for 404, 'Too many requests, try again later' for 429, 'Service unavailable' for 503. In the FALSE branch (success), continue with your normal data handling. Also add a conditional visibility on your results Container — only show it if the Backend Query has returned valid data.
Expected result: Users see a clear error message when the API fails instead of a blank screen. The app gracefully handles all common failure modes.
Complete working example
1API Group: WeatherAPI2├── Base URL: https://api.openweathermap.org/data/2.53├── Headers: (none shared — auth is per-call query param)4│5└── API Call: getCurrentWeather6 ├── Method: GET7 ├── Path: /weather8 ├── Query Params:9 │ ├── q: [Variable — city name from Page State]10 │ ├── appid: [Secret — WEATHER_API_KEY]11 │ └── units: metric12 └── Marked Response Fields:13 ├── main > temp (Double)14 ├── main > humidity (Integer)15 ├── main > feels_like (Double)16 ├── weather > 0 > description (String)17 ├── weather > 0 > icon (String)18 ├── wind > speed (Double)19 └── name (String — city name as confirmed by API)2021Page Setup: WeatherPage22├── Page State: cityName (String, default: 'London')23├── Backend Query: getCurrentWeather24│ └── q param: bound to Page State cityName25│26├── Widget Tree:27│ ├── TextField: city search input28│ │ └── On Submit: update Page State cityName29│ ├── Text: city name (from API response: name)30│ ├── Image: weather icon31│ │ └── URL: https://openweathermap.org/img/wn/{icon}@2x.png32│ ├── Text: temperature (temp + '°C')33│ ├── Text: description (weather[0].description)34│ ├── Text: humidity ('Humidity: ' + humidity + '%')35│ └── Text: wind ('Wind: ' + wind.speed + ' m/s')36│37Action Flow: Search Button38├── Update Page State: cityName = TextField value39├── Backend Query: refresh getCurrentWeather40├── Conditional: if status != 20041│ └── True: Show Snackbar 'City not found or API error'42└── Conditional: if status == 20043 └── True: show results containerCommon mistakes
Why it's a problem: Not handling API errors in the Action Flow — app shows blank screen on failure
How to avoid: After every API Call action, add a Conditional checking the response status code. Handle 404 (not found), 401/403 (auth failure), 429 (rate limit), and 5xx (server error) with distinct user-facing messages.
Why it's a problem: Hardcoding API keys in the API Group headers instead of using Secrets
How to avoid: Store API keys in FlutterFlow Secrets (Settings → Secrets) and reference them with [secretName] syntax in headers or parameters. For highly sensitive credentials, route through a Cloud Function that adds auth server-side.
Why it's a problem: Placing the Backend Query on a widget deep in the tree instead of the page
How to avoid: Attach the Backend Query to the page itself or to the highest-level Container that contains all the widgets needing the data. Children inherit access, siblings and parents do not.
Best practices
- Test every API call in the Response & Test tab before building UI — confirms authentication and response structure before wiring up widgets
- Use Variable type for API parameters rather than hardcoded values so callers can pass dynamic inputs like search terms, user IDs, or date ranges
- Store API keys in FlutterFlow Secrets for any key that has write access or billing implications — safe read-only keys with strict rate limits are lower risk
- Add a loading state (CircularProgressIndicator or shimmer skeleton) while the Backend Query is in-flight so users see feedback immediately
- Cache API responses in Firestore for data that does not change frequently — product catalogs, configuration, reference data — to reduce API calls and improve load speed
- Use the API Group's shared headers for common values like Content-Type and authentication, keeping individual calls clean and focused on their specific parameters
- Check the API's rate limit documentation before launch and implement retry logic with exponential backoff for 429 errors in production apps
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I am building a FlutterFlow app and need to integrate a REST API. The API uses Bearer token authentication and returns nested JSON. Walk me through: (1) creating an API Group in FlutterFlow's API Manager with a shared Authorization header, (2) adding a GET endpoint with a path variable and query parameters, (3) testing the call and marking response fields, (4) binding the response to a ListView using Generate Dynamic Children, and (5) handling error status codes in the Action Flow.
Set up a weather display page in my FlutterFlow app that calls the OpenWeatherMap current weather API. Show the city name, temperature in Celsius, weather description, humidity, and the weather icon image. Add a search TextField so users can look up any city. Show a Snackbar if the city is not found.
Frequently asked questions
How do I add an external REST API to FlutterFlow?
Go to API Manager in the left sidebar → Add API Group → enter the base URL and any shared headers. Then click Add API Call within the group to define each endpoint: set the method, path, parameters, and request body. Use the Response & Test tab to call the API and mark the JSON fields you need for data binding.
Can I use APIs that require OAuth authentication in FlutterFlow?
For APIs using OAuth 2.0 where the token exchange involves a client secret, you must proxy through a Cloud Function. The Cloud Function handles the token exchange, stores the access token, and exposes a simplified endpoint that FlutterFlow calls. For Bearer token APIs where you already have a long-lived token (e.g., personal access tokens), add the Authorization: Bearer {token} header directly in the API Group.
How do I pass dynamic values like a search term or user ID to an API call in FlutterFlow?
In the API Call definition, set the parameter type to Variable instead of a hardcoded value. When you call the API from an Action Flow or Backend Query, FlutterFlow will prompt you to supply values for these variable parameters. Bind them to Page State, App State, component parameters, or the current user's auth UID.
Why does my API call return data in the test but not in the app?
This usually means a variable parameter is empty at runtime. The test tab uses the sample values you entered manually, but in the running app those values come from Page State or user input. Check that the Page State variable is initialized with a default value and that it is being updated before the API call triggers.
What is the difference between a Backend Query and calling an API in an Action Flow?
A Backend Query automatically loads data when the page or widget is built and can refresh on a timer or trigger. It is ideal for displaying data that loads on page open. An Action Flow API call runs on demand in response to user actions like a button tap. Use Backend Query for initial data loads and Action Flow calls for search, form submissions, and triggered operations.
What if the API I need has restrictions that block direct client calls?
Some APIs enforce server-to-server calls only, require credentials that must not be in client code, or need server-side request signing. In those cases, create a Firebase Cloud Function that accepts simplified parameters from FlutterFlow, adds the proper auth, calls the external API, and returns the processed result. RapidDev has configured hundreds of Cloud Function API proxies for FlutterFlow apps across many industries.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation