Postman

Open Postman (desktop or browser) and create a new request. Paste the full API endpoint URL into the request URL bar, including any base URL and path (e.g., https://api.openweathermap.org/data/2.5/weather). Set the method (GET, POST, PUT, DELETE) using the dropdown to the left of the URL bar — match it to the API documentation. Next, add authentication. In Postman, click the 'Auth' tab below the URL bar. Choose the auth type your API uses from the dropdown: 'Bearer Token' (for OAuth2 and most modern APIs), 'Basic Auth' (for username/password or username/API token combinations), or 'API Key' (for a single key in a header or query param). Postman automatically formats the header for you when you select the type and enter the value — this is helpful because you'll need to know the exact header format when recreating it in FlutterFlow. For query parameters, click the 'Params' tab and add key-value pairs (e.g., 'q' = 'London', 'units' = 'metric', 'appid' = 'your-key'). Postman appends these to the URL automatically. For POST requests with a JSON body, click the 'Body' tab, select 'raw', choose 'JSON' from the format dropdown, and paste your request JSON. Once all fields are filled in, click 'Send'. A successful response shows a 200 (or 201) status code in the bottom panel with the JSON body. If you see 401, your credentials are wrong. If you see 403, you have the wrong scope or permissions. If you see 404, the endpoint URL is incorrect. Fix any errors in Postman before proceeding — do not move to FlutterFlow until Postman returns a clean 200 response.

With a working request in Postman, extract the two key pieces of information FlutterFlow needs: the exact request format and the exact response structure. For the request format: in Postman, click the 'Code' icon (the </> symbol, in the right panel or under the three-dot menu). Select 'cURL' from the language dropdown. Postman generates a curl command that includes every header, query parameter, and body field used in your successful request. This curl output is a direct map to FlutterFlow: - '-H "Authorization: Bearer xxx"' → FlutterFlow API Call > Headers > Authorization: Bearer {{userToken}} - '-H "Content-Type: application/json"' → Headers > Content-Type: application/json - '?q=London&units=metric' → FlutterFlow > Variables tab: add 'city' (String) and 'units' (String), then use them in the URL as ?q={{city}}&units={{units}} - '-d \'{ "name": "John" }\'' → FlutterFlow > Body tab: paste the JSON with {{variable}} substitutions For the response structure: look at the JSON response body in Postman's response panel. Click the '...' button and 'Copy response' to copy the full JSON. In FlutterFlow, open the API Call > Response & Test tab > paste this JSON as a sample response > click 'Generate JSON Paths'. FlutterFlow parses the structure and offers to create response variables for each field. The JSON paths it generates ($.data.items[0].name, $.weather[0].description, etc.) are exactly what you would have needed to figure out manually — Postman's response gives you this for free. Note: Postman 'Bearer Token' auth = FlutterFlow header 'Authorization: Bearer {{token}}'. Postman 'Basic Auth' with username/password = FlutterFlow header 'Authorization: Basic {base64(username:password)}'. Postman 'API Key' in header = FlutterFlow header with the same key name and value. The naming conventions differ between tools but the HTTP headers are identical.

1// Postman cURL export → FlutterFlow API Call mapping example
2// Postman cURL:
3// curl --location 'https://api.example.com/v1/data?type=recent'
4// --header 'Authorization: Bearer YOUR_TOKEN'
5// --header 'Content-Type: application/json'
6
7// Equivalent FlutterFlow API Call configuration:
8{
9  "group_name": "ExampleAPI",
10  "base_url": "https://api.example.com/v1",
11  "headers": {
12    "Content-Type": "application/json",
13    "Authorization": "Bearer {{userToken}}"
14  },
15  "calls": [
16    {
17      "name": "GetRecentData",
18      "method": "GET",
19      "path": "/data",
20      "query_params": { "type": "recent" },
21      "variables": [
22        { "name": "userToken", "type": "String" }
23      ]
24    }
25  ]
26}

Open FlutterFlow and click API Calls in the left navigation panel. Click + Add > Create API Group. Name the group after the API service you are integrating (e.g., 'OpenWeatherMap', 'ExampleCRM', 'MyInternalAPI'). Set the Base URL to the API's base URL — typically the protocol + domain without any path (e.g., https://api.openweathermap.org/data/2.5). Splitting the URL into base URL + path (set per-call) makes it easy to add more calls to the same API later. Under 'Headers' in the API Group, add any headers that apply to ALL calls in this group (e.g., Content-Type: application/json, or an Authorization header that is the same for all endpoints). For headers that vary per-call (like a dynamic user token), leave the group header empty and add it per-call with a {{variable}} substitution. Now click + Add API Call inside the group. Name it after the operation (e.g., 'GetCurrentWeather'). Set Method to match Postman (GET, POST, etc.). Set the Path to the endpoint path you saw in Postman's URL (e.g., '/weather'). Switch to the Variables tab and add a variable for every dynamic value you used in Postman: 'city' (String), 'apiKey' (String — you will substitute this from a secure source, not hardcode it), 'units' (String with default 'metric'). In the URL and header fields, reference these variables as {{city}}, {{apiKey}}, {{units}}. For POST requests with a body: click the Body tab, set the format to JSON, and paste the request body template with {{variable}} placeholders replacing the actual values you used in Postman. FlutterFlow substitutes them at runtime based on the variables you defined. For the API key: do not put the actual key value in FlutterFlow. Instead, set up a Firebase Cloud Function or Supabase Edge Function proxy that holds the key as an environment variable, and point FlutterFlow's API Call at the proxy URL instead of the API directly. The proxy forwards the request to the real API with the key injected server-side.

The response from your successful Postman test is the source of truth for FlutterFlow's JSON path bindings. Open the API Call in FlutterFlow and click the 'Response & Test' tab. In the 'Sample Response' field, paste the JSON body that Postman returned (copy it from Postman's response panel using 'Copy response'). Click 'Generate JSON Paths'. FlutterFlow parses the JSON and suggests response variables for each field and array in the response. For each variable it identifies, FlutterFlow assigns a JSON path like $.data.items, $.weather[0].main, $.user.profile.name. Click the checkbox next to each field you want to use in your app. Give each variable a descriptive name (e.g., 'temperature', 'weatherDescription', 'cityName'). For array responses (like a list of items), FlutterFlow identifies the array path (e.g., $.results) and generates an item-level path for fields within each item ($.results[0].id, $.results[0].title). When you bind this API Call to a ListView in the widget tree, FlutterFlow uses the array path to generate list items and the item paths to populate each card's fields. For nested objects, the JSON path uses dot notation: $.user.address.city refers to { user: { address: { city: 'London' } } }. Postman's response tree view (click 'Pretty' in the response panel) shows the exact nesting so you can verify the path structure before pasting it into FlutterFlow. After generating paths, click 'Test' in FlutterFlow's Response & Test tab. FlutterFlow sends a real request using the variables you define as test inputs. If the response matches your Postman response (same fields, same values for the same inputs), the JSON paths are correct and your API Call is ready to bind to widgets.

1// Example: Postman response → FlutterFlow JSON path mapping
2// Postman response body:
3{
4  "coord": { "lon": -0.1257, "lat": 51.5085 },
5  "weather": [{ "id": 800, "main": "Clear", "description": "clear sky", "icon": "01d" }],
6  "main": { "temp": 22.4, "feels_like": 21.8, "humidity": 52 },
7  "name": "London",
8  "cod": 200
9}
10
11// FlutterFlow JSON paths to create:
12// temperature  → $.main.temp
13// feelsLike    → $.main.feels_like
14// humidity     → $.main.humidity
15// weatherDesc  → $.weather[0].description
16// cityName     → $.name

In Postman, it is common to store API keys in Postman environment variables (e.g., {{API_KEY}}) so you can reuse them across requests and switch between development and production keys. These Postman variables exist only in Postman — they do not carry over to FlutterFlow automatically. When you recreate the request in FlutterFlow, you cannot use the same approach of storing the key in FlutterFlow's App State or App Values, because both are compiled into the app binary and can be extracted by anyone who decompiles the APK or IPA. The secure approach: any key that would be a secret in Postman's environment variables must live in a backend proxy when moving to FlutterFlow. Create a Firebase Cloud Function or Supabase Edge Function that stores the key as an environment variable. The function receives a request from FlutterFlow (with only non-secret parameters like a city name or a user ID), adds the secret API key server-side, calls the real API, and returns the response to FlutterFlow. In FlutterFlow, update your API Call group's base URL to point to the proxy function URL instead of the real API URL. Remove the API key variable from the FlutterFlow API Call configuration entirely — it is no longer needed there. This way, your FlutterFlow app never handles the secret key. For publishable keys — keys designed to be used in client apps, like a Stripe publishable key (pk_live_...) or a Google Maps API key restricted by app bundle ID — it is acceptable to include them in FlutterFlow's App Values or API Call headers. These are public by design. The distinction: secret keys (sk_live_..., server-to-server tokens, private API keys) must be proxied; publishable keys (pk_live_..., public API keys, client IDs) are fine in FlutterFlow. If you're not sure which category your key falls into, check the API documentation — it will explicitly state whether the key is 'secret' or 'publishable/client-safe'. RapidDev's team regularly sets up FlutterFlow proxy integrations for APIs that require secret keys — free scoping call at rapidevelopers.com/contact if you'd prefer expert help with this step.

1// Supabase Edge Function proxy — holds secret API key
2// Deploy via Supabase Dashboard > Edge Functions
3
4Deno.serve(async (req) => {
5  const corsHeaders = {
6    'Access-Control-Allow-Origin': '*',
7    'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
8    'Access-Control-Allow-Headers': 'Content-Type',
9  };
10
11  if (req.method === 'OPTIONS') {
12    return new Response(null, { headers: corsHeaders });
13  }
14
15  const url = new URL(req.url);
16  const city = url.searchParams.get('city') ?? 'London';
17  const units = url.searchParams.get('units') ?? 'metric';
18
19  // Secret key lives here, not in FlutterFlow
20  const apiKey = Deno.env.get('WEATHER_API_KEY');
21
22  const apiUrl =
23    `https://api.openweathermap.org/data/2.5/weather?q=${city}&units=${units}&appid=${apiKey}`;
24
25  const response = await fetch(apiUrl);
26  const data = await response.json();
27
28  return new Response(JSON.stringify(data), {
29    headers: { ...corsHeaders, 'Content-Type': 'application/json' },
30    status: response.status,
31  });
32});

The last and often-forgotten step is testing in the actual runtime environment, not just FlutterFlow's editor. There are three levels of testing for a FlutterFlow API integration, and a request can succeed in some while failing in others: Level 1 — Postman: The most permissive test. Postman sends requests directly from your computer without browser CORS enforcement. A 200 here proves your credentials and endpoint are correct, but it does not predict browser behavior. Level 2 — FlutterFlow's API Test tab: Also runs from FlutterFlow's servers (not your browser), so CORS is not enforced. Passing here confirms FlutterFlow can reach your proxy and parse the response. This is still not the browser. Level 3 — FlutterFlow Run mode or device build: This is the real test. When you click Run (web) in FlutterFlow, the app runs in your browser. The browser enforces CORS — if the API (or your proxy) does not return Access-Control-Allow-Origin: * (or your specific origin) in its response headers, the browser blocks the request with an 'XMLHttpRequest error'. Mobile app builds do not enforce CORS, so if you only see CORS failures on web and not on a device, that confirms the issue is browser CORS rather than an auth or network problem. To test: click the Run button in FlutterFlow's top toolbar. The app opens in a new browser tab. Navigate to the page with your API Call. If the data populates correctly, your integration is working end-to-end in the web build. Then test on a physical iOS or Android device (using FlutterFlow's device testing QR code) to confirm the native mobile experience as well. If you see the data in the FlutterFlow Test tab but not in Run mode, the cause is CORS. The fix: ensure your backend proxy returns the correct CORS headers. If you are calling a third-party API directly (without a proxy) and it does not support CORS, you must add a proxy — there is no other solution for web builds.