RapidAPI

Log in to rapidapi.com and use the search bar to find the API you want to connect — for example, a weather API, sports scores API, or translation engine. On the API's page, click the Subscribe button and choose a plan. Most APIs offer a free Basic or Freemium plan with a monthly quota of requests; note what that quota is now, because hitting it produces a 429 error that looks like a code bug. Once subscribed, navigate to the Endpoints tab and select any endpoint you plan to use. On the right side you will see a Code Snippets panel with a dropdown — choose cURL. The generated snippet contains everything FlutterFlow needs: the full endpoint URL broken into a base host and path, the two required headers (X-RapidAPI-Key and X-RapidAPI-Host), and any query parameters the endpoint accepts. Copy this snippet and paste it into a text editor so you can refer to the exact field names while setting up FlutterFlow. Also paste one of the API's sample JSON responses into a text editor — you will need the field paths (like data.location.name or current.temp_c) when you configure JSON Path parsing in FlutterFlow later.

In your FlutterFlow project, click API Calls in the left navigation panel. Click the + Add button and choose Create API Group. Give the group a descriptive name that matches the API, such as WeatherAPI or SportsScores. Set the Base URL to the API's RapidAPI host — this is the https://{api-name}.p.rapidapi.com part of the URL in your cURL snippet. Each API on RapidAPI has a different host value; copying the wrong one will send your requests to the wrong service. Do not add any headers yet at the group level. Now add a call inside the group: click + Add API Call and name it after the specific endpoint, such as GetCurrentWeather. Set the HTTP Method to GET (or POST if the endpoint requires a body — check the Code Snippet). In the URL field enter the path portion only, for example /current.json, because the base URL is already set on the group. This split prevents you from duplicating the host on every call. Switch to the Headers tab of this API Call. Add two headers exactly as shown in the cURL snippet. The first header name must be X-RapidAPI-Key and its value will be a variable you define in the next step (use {{ rapidAPIKey }} as a placeholder for now). The second header name must be X-RapidAPI-Host and its value is the static host string from your snippet, for example weatherapi.p.rapidapi.com. This host value is not a secret — it is safe to enter it directly. Missing either header will return a 403 even when your key is valid.

1{
2  "group_name": "WeatherAPI",
3  "base_url": "https://weatherapi-com.p.rapidapi.com",
4  "calls": [
5    {
6      "name": "GetCurrentWeather",
7      "method": "GET",
8      "path": "/current.json",
9      "headers": {
10        "X-RapidAPI-Key": "{{ rapidAPIKey }}",
11        "X-RapidAPI-Host": "weatherapi-com.p.rapidapi.com"
12      },
13      "query_params": {
14        "q": "{{ city }}"
15      }
16    }
17  ]
18}

Switch to the Variables tab of your API Call. Click + Add Variable for each parameter the endpoint accepts. For a weather API this is usually a city or location query parameter (q); for a sports API it might be a season or team ID. Set each variable's type (String, Integer) and whether it is required. Once you have added variables, go back to the URL field or the Query Parameters section and reference them with the {{ variableName }} syntax. For a query parameter, use the Query Params section rather than embedding it in the URL path — this is cleaner and FlutterFlow handles encoding automatically. Now click the Response & Test tab. Paste your sample JSON response into the Response Preview field and click Generate JSON Paths. FlutterFlow scans the JSON and suggests paths for each field it finds. Enable the paths you want to expose as response variables — for example, $.current.temp_c for current temperature and $.location.name for the resolved city name. Rename each to a friendly variable name (tempCelsius, locationName) that will appear in widget bindings. If the response is an array, paths like $.data[0].name or $.results[*].title give you list access. With variables and JSON Paths configured, click Test in the Response & Test tab. Enter real values for your variables (an actual city name, not a placeholder) and run the call. If you see real data populating the response variables, the call is correctly configured. A 403 here means the key or host header is wrong; a 429 means the free-tier quota is already exhausted for the month.

1// JSON Path examples for a weather API response
2// Response: { "location": { "name": "London", "country": "UK" }, "current": { "temp_c": 14.0, "condition": { "text": "Partly cloudy" } } }
3
4$.location.name          // → "London"
5$.location.country       // → "UK"
6$.current.temp_c         // → 14.0
7$.current.condition.text // → "Partly cloudy"
8
9// For an array response:
10// Response: { "results": [ { "id": 1, "title": "Match A" } ] }
11$.results[0].title       // → first item title
12$.results[*].title       // → all titles as a list

Now that your API Call is tested and returning data, wire it to the UI. For a single-item response (current weather, one user profile), select the widget you want to populate — for example, a Text widget showing the temperature. Open its Actions panel and click + Add Action. Choose Backend/API Calls, select your API Group, then your API Call. FlutterFlow shows a list of the response variables you defined with JSON Paths. Set each widget's text or image source to the corresponding response variable using the Set Variable action, or use the widget's inline data source picker to bind directly. For list responses (search results, sports fixtures), place a ListView or Column widget on the page. Set its data source to a backend query that fires your API Call with the appropriate variables, then map each item's fields to child widgets using the item index binding. If you pass user-entered values (city name, search term) as variables, connect the text field's value to the variable that drives the API Call query parameter. A search bar with a debounce Action that fires the API Call on text-changed works well here. For loading states, wrap the data-bound widget in a Conditional Widget that shows a CircularProgressIndicator while the backend query is in progress, and a user-friendly error message if the API Call returns a non-200 status. Check the conditional status using the API response's success/error state rather than hard-coding delays.

The X-RapidAPI-Key unlocks every API subscription you own. If you place it in a FlutterFlow App Value, App State variable, or directly in the header field, it ships inside the compiled Flutter binary — any user with basic reverse-engineering tools can extract it, rotate it fraudulently, or exhaust your quota. The correct pattern for production apps is a thin server-side proxy that holds the key and adds both RapidAPI headers before forwarding the request. If your project uses Firebase: create a Firebase Cloud Function (Node.js). The function accepts the parameters your FlutterFlow app sends (city name, sport ID, etc.), adds the X-RapidAPI-Key and X-RapidAPI-Host headers from process.env, calls the RapidAPI endpoint, and returns the JSON response. Deploy it with firebase deploy --only functions. Store the key in Firebase environment config (firebase functions:config:set rapidapi.key=xxx) rather than in source code. If your project uses Supabase: create a Supabase Edge Function (Deno). The function reads the RapidAPI key from Deno.env.get('RAPID_API_KEY'), calls the endpoint, and returns the response. Set the secret in the Supabase Dashboard under Edge Functions > Secrets. Once the proxy is deployed, update your FlutterFlow API Calls group to point at your proxy URL instead of the RapidAPI host directly. The proxy URL is your Firebase function or Supabase Edge Function endpoint. Remove the X-RapidAPI-Key header from the FlutterFlow API Call — it is now handled server-side. You can keep X-RapidAPI-Host absent too since the proxy hard-codes the target. For extra security, add a simple secret header between your app and your proxy (a different token your app sends, validated on the proxy) to prevent unauthorized direct calls to your proxy endpoint.

1// Firebase Cloud Function proxy (index.js)
2const functions = require('firebase-functions');
3const axios = require('axios');
4
5exports.rapidApiProxy = functions.https.onCall(async (data, context) => {
6  const { endpoint, params } = data;
7
8  // Allowlist endpoints to prevent abuse
9  const allowedEndpoints = ['/current.json', '/forecast.json'];
10  if (!allowedEndpoints.includes(endpoint)) {
11    throw new functions.https.HttpsError('invalid-argument', 'Endpoint not allowed');
12  }
13
14  const response = await axios.get(
15    `https://weatherapi-com.p.rapidapi.com${endpoint}`,
16    {
17      headers: {
18        'X-RapidAPI-Key': functions.config().rapidapi.key,
19        'X-RapidAPI-Host': 'weatherapi-com.p.rapidapi.com'
20      },
21      params
22    }
23  );
24
25  return response.data;
26});

RapidAPI free-tier quotas vary by API — some allow 500 requests per month, others 10 per day. A quota hit returns HTTP 429 with a message like 'You have exceeded the rate limit per month for your plan, BASIC.' This looks identical to a rate-limit error from a code bug, so add explicit handling: in your FlutterFlow Action Flow, check the API Call's response code. If it equals 429, show a Snackbar or Dialog that tells the user 'API limit reached — please try again later' rather than showing a generic error or blank screen. For 403 responses, the most common cause is the missing X-RapidAPI-Host header. In the proxy flow, 403 can also mean the proxy function's environment variable is not set correctly. Log the RapidAPI error body ('message' field) in your Cloud Function to diagnose quickly. FlutterFlow's API Test tab runs on Rapid's servers and does not enforce CORS — so a request that passes in the Test tab can still fail in the web preview because browsers enforce CORS. For web builds, use the proxy pattern: your Cloud/Edge Function is the browser's origin-safe URL. For native iOS/Android builds, CORS is not enforced and the direct API Call header approach would work, but use the proxy anyway for key security. Before shipping to the App Store or Play Store, run a build on a physical device or the FlutterFlow Run mode (not canvas preview) to confirm real data loads. Custom Actions and API Calls that use variables from UI elements (text fields, dropdowns) must be tested in Run mode because the canvas only simulates static data.