Planoly

Planoly's API is not a self-serve dashboard toggle. Before writing a single line of proxy code or configuring a FlutterFlow API Call, you need explicit approval from Planoly. Go to planoly.com/developer or contact Planoly support directly and request developer API access. Be ready to describe what you intend to build (a mobile FlutterFlow companion app), what endpoints you need (scheduled posts, media library), and which Planoly plan your account is on. This step can take anywhere from a day to a week depending on Planoly's current developer programme availability. Do not skip it — building the proxy and FlutterFlow screens before access is approved means you will be testing against an API that returns 401 or 403 errors no matter how correct your code is. Once approved, Planoly will provide you with an API token and the current base URL. The base URL is not publicly documented in a fixed location and may change, so always confirm the exact host from the documentation or communication you receive at approval time. Note both values down — you will need them for the proxy in the next step.

Because FlutterFlow compiles your app to run on the user's device, any credential placed in an API Call header is embedded in the compiled app bundle. Anyone who downloads your app can extract it with standard tools and use it to read or modify your entire Planoly content plan. The solution is a server-side proxy: a Firebase Cloud Function (Node.js) or Supabase Edge Function (Deno) that holds the token in an environment variable and forwards requests to Planoly on behalf of the app. For Firebase: open the Firebase console, navigate to Functions, and deploy a new HTTPS function. Store the Planoly API token in Firebase environment config or Secret Manager (not in the function source code). The function receives requests from your FlutterFlow app, validates the caller (e.g. checks a Firebase Auth token), adds the Planoly Bearer token to the Authorization header, and forwards the request to the Planoly base URL you confirmed in step 1. For Supabase: open the Supabase dashboard, go to Edge Functions, create a new function, and add the Planoly token as a Supabase secret. The Edge Function receives the FlutterFlow request, adds the token, and proxies to Planoly. The example below shows a Firebase Cloud Function pattern. Replace `YOUR_PLANOLY_BASE_URL` with the exact host confirmed at approval time, and store `PLANOLY_API_TOKEN` as an environment variable or secret — never hardcode it in the source.

1// Firebase Cloud Function: Planoly proxy
2// index.js (Node.js 18+)
3const functions = require('firebase-functions');
4const { https } = require('firebase-functions/v2');
5const fetch = require('node-fetch');
6
7const PLANOLY_BASE_URL = process.env.PLANOLY_BASE_URL || 'https://YOUR_PLANOLY_BASE_URL';
8const PLANOLY_TOKEN = process.env.PLANOLY_API_TOKEN;
9
10exports.planolyProxy = https.onRequest(async (req, res) => {
11  // Set CORS for web builds if needed
12  res.set('Access-Control-Allow-Origin', '*');
13  if (req.method === 'OPTIONS') {
14    res.set('Access-Control-Allow-Methods', 'GET, POST');
15    res.set('Access-Control-Allow-Headers', 'Content-Type, Authorization');
16    res.status(204).send('');
17    return;
18  }
19
20  const path = req.query.path || '/scheduled_posts';
21  const planolyUrl = `${PLANOLY_BASE_URL}${path}`;
22
23  try {
24    const response = await fetch(planolyUrl, {
25      method: req.method,
26      headers: {
27        'Authorization': `Bearer ${PLANOLY_TOKEN}`,
28        'Content-Type': 'application/json'
29      },
30      body: req.method !== 'GET' ? JSON.stringify(req.body) : undefined
31    });
32
33    const data = await response.json();
34    res.status(response.status).json(data);
35  } catch (err) {
36    res.status(500).json({ error: 'Proxy error', details: err.message });
37  }
38});

Now that your proxy is running, you configure FlutterFlow to call it — not the Planoly API directly. In FlutterFlow, click API Calls in the left navigation panel. Click the blue + Add button and choose Create API Group. Name the group something descriptive like `PlanolyProxy`. Set the Base URL to your deployed proxy URL — for example, `https://us-central1-your-project.cloudfunctions.net/planolyProxy` (Firebase) or `https://your-project.supabase.co/functions/v1/planoly-proxy` (Supabase). You do not need to add any authentication headers in the FlutterFlow API Group — those are handled in the proxy. You may optionally add a query parameter variable named `path` so individual API Calls in the group can specify different Planoly endpoints (e.g. `/scheduled_posts`, `/media`). Click Save to save the API Group. With the group saved, click + Add again inside the group and choose Add API Call. Name it `GetScheduledPosts`. Set the Method to GET. In the Variables tab, add a variable named `path` with the default value `/scheduled_posts` (or the specific endpoint path provided by Planoly). In the URL field, confirm that the variable is referenced as `?path={{ path }}`. Click the Response & Test tab, paste a sample JSON response from Planoly (you can get one from a direct proxy call), and click Generate JSON Paths. FlutterFlow will automatically generate JSON path extractors for each field in the response — for example `$.posts[0].thumbnail_url`, `$.posts[0].scheduled_time`, `$.posts[0].caption`. Name these paths clearly so you can bind them to widgets later.

1// Example API Call config (reference for understanding the setup)
2{
3  "api_group": "PlanolyProxy",
4  "base_url": "https://us-central1-YOUR-PROJECT.cloudfunctions.net/planolyProxy",
5  "call_name": "GetScheduledPosts",
6  "method": "GET",
7  "query_params": {
8    "path": "/scheduled_posts"
9  },
10  "json_paths": {
11    "postsList": "$.posts",
12    "firstThumbnail": "$.posts[0].thumbnail_url",
13    "firstCaption": "$.posts[0].caption",
14    "firstScheduledTime": "$.posts[0].scheduled_time"
15  }
16}

Before binding Planoly data to widgets, create a FlutterFlow Data Type to represent a scheduled post cleanly. Go to the Data Types section in the left nav (the database icon), click + Add Data Type, and name it `PlanolyPost`. Add fields that match the JSON paths you generated: `thumbnailUrl` (String), `caption` (String), `scheduledTime` (String or DateTime), `platform` (String for Instagram/Pinterest), and any other relevant fields like `postId` (String) or `mediaType` (String for image/video/story). Back in the API Call settings, map the JSON paths to a list of `PlanolyPost` objects. In FlutterFlow's Response tab, set the Response Type to `List of PlanolyPost` and map each path to the corresponding field. This means your widget tree can bind to a typed list of posts rather than raw JSON, which makes the GridView binding in the next step much cleaner. For the scheduled time field, if Planoly returns a Unix timestamp or an ISO 8601 string, FlutterFlow's DateTime type and formatting functions can convert it to a human-readable format for display. Store it as String if the format is uncertain — you can always format it in the widget with a conditional expression. Also create a second API Call in the same group called `GetMediaLibrary` for fetching the media library, if you intend to support media browsing in addition to the schedule view. The same proxy path-variable approach works for any additional Planoly endpoint you need.

The signature FlutterFlow build for Planoly is the 3-column thumbnail grid that mimics the Instagram grid preview. In FlutterFlow's canvas, open the screen where you want to show the grid. In the widget panel, add a GridView widget. In the Properties panel on the right, set the Cross Axis Count to 3 (this creates three columns). Set the Cross Axis Spacing and Main Axis Spacing to a small value like 2 to mimic the thin gaps between Instagram grid tiles. Set the Child Aspect Ratio to 1.0 so each cell is square. Inside the GridView, add an Image widget as the child. In the Image widget's source property, choose Network Image and bind it to the `thumbnailUrl` field of each `PlanolyPost` in your list. To power the GridView with data, select the GridView widget and click the Generate Dynamic Children button (or use the widget's Backend Query settings). Set it to use the `GetScheduledPosts` API Call. FlutterFlow will pass each item in the returned `List of PlanolyPost` into the child widget as a variable, so the Image source becomes `currentPost.thumbnailUrl`. For lazy loading, enable the Image widget's caching option (FlutterFlow sets this with `fit: BoxFit.cover` and standard Flutter image caching by default — images are cached once downloaded and don't re-fetch on scroll). Add an InkWell or GestureDetector around the Image widget to handle taps, opening a detail screen that shows the full caption and scheduled time. The scheduled time display can use FlutterFlow's text widget with a DateTime format function applied to `currentPost.scheduledTime`. To refresh the grid, add a Refresh button (an IconButton with a refresh icon in the AppBar) that triggers the `GetScheduledPosts` API Call action and updates the page state variable holding the posts list.

The Instagram grid preview screen is likely to be the most-viewed screen in your app — users will open it frequently to check their upcoming posts. Without caching, every screen open fires a new API Call through your proxy to Planoly, increasing the risk of hitting per-account rate limits and adding noticeable load time to each grid open. The caching strategy is simple: store the fetched post list in a FlutterFlow App State variable (a `List of PlanolyPost`) and track the last-fetched timestamp in a second App State variable (a DateTime). On screen open, check the App State timestamp. If the last fetch was more than a few minutes ago (3-5 minutes is a reasonable starting point for a content calendar that doesn't change by the second), fire the `GetScheduledPosts` API Call and update both the posts list and the timestamp. If the last fetch was recent, render the App State list directly without making a network call. In FlutterFlow, implement this with a Conditional Action in the page's On Page Load action block: first check `(currentTime - lastFetchedAt) > 3 minutes`, then branch to either a fresh API call or a no-op. For the proxy side, you can also add a short server-side cache: store the Planoly response in Firestore or Supabase with a TTL, so that if two users of the same account open the app simultaneously, both get the cached response rather than firing duplicate Planoly API calls. This is especially useful in a team scenario where multiple team members use the app to review the same content calendar. Monitor your Planoly API usage in the developer portal after launch to confirm the caching interval is keeping calls well within the allowed rate.