Buffer

Go to buffer.com/developers (or the Buffer Developer portal from your account settings) and create a new developer application. Give it a name, set a redirect URI (for OAuth flow — even if you use a personal token initially, a valid redirect URI is required to create the app), and save it. Buffer will give you a client ID and client secret. For a single-user app or internal tool, the simplest path is a personal access token: in the Buffer developer portal, look for the option to generate a personal access token for your account. Copy this token — you will add it to your proxy function's environment variables in the next step. Note that a personal token gives access to the account that generated it, not to any user who logs into your app. For a multi-user app where each user connects their own Buffer account, you need the full OAuth 2.0 Authorization Code flow. In that case, the OAuth token exchange happens in your Firebase/Supabase proxy: the user taps 'Connect Buffer' in the app, gets redirected to Buffer's authorization page, Buffer redirects back to your proxy callback with a code, and the proxy exchanges the code for a Bearer token and stores it per user. For this tutorial, we focus on the personal-token flow first, then mention the OAuth extension in the proxy step. Verify current API access tiers with Buffer's developer documentation to confirm which plan level grants API access.

Every Buffer API call from your FlutterFlow app must go through a server-side proxy — not directly to `api.bufferapp.com`. The reason: FlutterFlow compiles to a Flutter client app that runs on the user's device. Any value you put in a FlutterFlow API Call header ships inside the compiled binary. Anyone who downloads your app can extract the Bearer token and use it to post to every social channel connected to the Buffer account, delete scheduled posts, or read private queue data. The proxy keeps the token in an environment variable on the server, visible only to your backend code. The Firebase Cloud Function below handles both the `/profiles` and `/updates/create` paths by forwarding requests to Buffer with the token in the Authorization header. Store the access token in Firebase Secret Manager or as a Firebase Functions environment variable — not in the function source code. Set the proxy's Firebase function URL as an environment variable or app config value that you reference from your FlutterFlow API Call base URL. If you use Supabase, deploy the equivalent Deno Edge Function and store the token as a Supabase secret.

1// Firebase Cloud Function: Buffer proxy
2// index.js (Node.js 18+)
3const { https } = require('firebase-functions/v2');
4const fetch = require('node-fetch');
5
6const BUFFER_TOKEN = process.env.BUFFER_ACCESS_TOKEN;
7const BUFFER_BASE = 'https://api.bufferapp.com/1';
8
9exports.bufferProxy = https.onRequest(async (req, res) => {
10  // CORS for web builds
11  res.set('Access-Control-Allow-Origin', '*');
12  if (req.method === 'OPTIONS') {
13    res.set('Access-Control-Allow-Methods', 'GET, POST');
14    res.set('Access-Control-Allow-Headers', 'Content-Type');
15    res.status(204).send('');
16    return;
17  }
18
19  const path = req.query.path || '/profiles.json';
20  const method = req.method;
21  const bufferUrl = `${BUFFER_BASE}${path}`;
22
23  const headers = {
24    'Authorization': `Bearer ${BUFFER_TOKEN}`,
25    'Content-Type': 'application/x-www-form-urlencoded'
26  };
27
28  // Buffer's API uses form-encoded bodies for POST requests
29  let body = undefined;
30  if (method === 'POST' && req.body) {
31    const params = new URLSearchParams();
32    Object.entries(req.body).forEach(([k, v]) => {
33      if (Array.isArray(v)) {
34        v.forEach(item => params.append(`${k}[]`, item));
35      } else {
36        params.append(k, v);
37      }
38    });
39    body = params.toString();
40  }
41
42  try {
43    const response = await fetch(bufferUrl, { method, headers, body });
44    const data = await response.json();
45    res.status(response.status).json(data);
46  } catch (err) {
47    res.status(500).json({ error: 'Proxy error', details: err.message });
48  }
49});

With the proxy running, configure FlutterFlow to call it. In FlutterFlow, click API Calls in the left navigation panel. Click + Add → Create API Group. Name the group `BufferProxy`. Set the Base URL to your deployed proxy URL — for example `https://us-central1-your-project.cloudfunctions.net/bufferProxy` (Firebase) or `https://your-project.supabase.co/functions/v1/buffer-proxy` (Supabase). You do not add any auth headers here; those are handled by the proxy. Add a variable to the API group named `path` (String type, default value empty). Individual API Calls in the group will pass different values for this variable to target different Buffer endpoints. Now add the first API Call inside the group. Click + Add → Add API Call. Name it `GetProfiles`. Set Method to GET. In the Variables tab, confirm the `path` variable is available. Set the URL to `?path=/profiles.json`. Click the Response & Test tab and run a test call. Buffer's `/profiles.json` returns an array of connected channel objects. Paste the sample response and click Generate JSON Paths. You will get paths for each profile's `id`, `service` (e.g. `twitter`, `linkedin`), `service_username`, and other fields. Add a second API Call named `CreateUpdate`. Set Method to POST. Add variables for `profileIds` (a list/array of profile ID strings), `text` (the post caption), and optionally `media` for image/link attachments. Set the URL to `?path=/updates/create.json`. In the Body tab, set the body to send these variables as a JSON object — the proxy will convert them to form-encoded format before sending to Buffer. If you need RapidDev's team to wire this up without going through the proxy setup yourself, they handle FlutterFlow integrations like this every week — free scoping call at rapidevelopers.com/contact.

1// Example API Call config (reference only — not code you paste in FlutterFlow)
2{
3  "api_group": "BufferProxy",
4  "base_url": "https://us-central1-YOUR-PROJECT.cloudfunctions.net/bufferProxy",
5  "calls": [
6    {
7      "name": "GetProfiles",
8      "method": "GET",
9      "url": "?path=/profiles.json",
10      "json_paths": {
11        "profilesList": "$",
12        "firstProfileId": "$[0].id",
13        "firstService": "$[0].service",
14        "firstUsername": "$[0].service_username"
15      }
16    },
17    {
18      "name": "CreateUpdate",
19      "method": "POST",
20      "url": "?path=/updates/create.json",
21      "body_variables": {
22        "text": "string",
23        "profile_ids": "List<String>"
24      }
25    }
26  ]
27}

Load the Buffer profiles into a FlutterFlow Data Type so the channel-selection screen has structured data to work with. Go to the Data Types section in the left nav, click + Add Data Type, and name it `BufferProfile`. Add fields: `profileId` (String), `service` (String — 'twitter', 'linkedin', 'facebook', etc.), `serviceUsername` (String), `serviceType` (String — 'page', 'profile', etc.), and `avatarHttps` (String for the profile's avatar image URL if available). On the channel-selection screen, add a ListView widget powered by the `GetProfiles` API Call. Inside each list item, show the `serviceUsername` and `service` fields (e.g. '@yourbrand on Twitter', 'Your Company on LinkedIn'). Add a Checkbox widget inside each list item. Store the selected profile IDs in a Page State variable of type `List<String>` named `selectedProfileIds`. When a checkbox is toggled on, append the profile's `profileId` to `selectedProfileIds`. When toggled off, remove it. Below the list, add a text input for the post caption and a Queue Post button. Disable the button when `selectedProfileIds` is empty (no channels selected) using a Conditional Visibility or Enable/Disable binding. On button tap, trigger the `CreateUpdate` API Call with the `text` variable set to the caption input value and the `profile_ids` variable set to the `selectedProfileIds` list. Load the profiles list on page open using an On Page Load action that calls `GetProfiles` and stores the result in a Page State list variable. Cache the profiles list in App State (not just Page State) since connected channels change infrequently — you only need to refetch profiles if the user connects a new channel.

The list of connected Buffer profiles changes rarely — a user might connect a new channel once a month at most. Fetching profiles on every screen open adds unnecessary latency and API calls. Store the profiles list in an App State variable of type `List of BufferProfile` so it persists across navigation events. On page open, check whether the App State profiles list is non-empty. If it is already populated, render it directly without calling the API. If it is empty (first launch or after the user explicitly refreshes), call `GetProfiles` and update the App State list. Add a Refresh Channels button (an IconButton in the AppBar) that clears the App State profiles list and triggers a fresh `GetProfiles` call. This gives the user a manual path to pick up newly connected channels without the app re-fetching on every open. For the queue viewer feature (showing pending posts), the queue changes much more frequently than profiles. Use a shorter refresh interval — call `GetUpdates` (which you can add to the API group as a third API Call targeting `/updates/pending.json?profile_id={{ profileId }}`) on every queue screen open, or add a pull-to-refresh gesture that triggers the call. Do not cache pending updates for long; a post that was just queued should appear immediately. Buffer's API rate limits are per-token, so verify current limits in the Buffer developer documentation and ensure your refresh frequency stays well within them.