Redis

Go to console.upstash.com and sign up or sign in with your Google or GitHub account — no credit card is needed for the free tier. Click 'Create Database'. Give it a name like 'flutterflow-cache'. Select the type 'Regional' (single region, lower latency) rather than 'Global' unless you specifically need multi-region replication. Choose the AWS or Google Cloud region closest to where your Cloud Functions or primary users are located — latency from a FlutterFlow app to Redis is the round-trip from the user's device, so pick a region that is geographically close. Once the database is created, you land on the database detail page. You need two values for FlutterFlow: the 'REST URL' (something like `https://us1-abc-12345.upstash.io`) and the 'REST Token' (a long string beginning with `AX...`). Click the eye icon to reveal the token. Copy both values — you'll paste them into FlutterFlow in the next step. Note: the REST Token gives full read/write access to the database. For your FlutterFlow integration, you'll use this token directly in the API Call header for safe read and increment operations. For destructive operations like FLUSHALL or DEL (delete all keys), you should route those through a Firebase Cloud Function that holds the same token server-side and validates the request before executing the command.

Open your FlutterFlow project. In the left navigation, click 'API Calls', then '+ Add' → 'Create API Group'. Name it 'Upstash'. Set the Base URL to your Upstash REST URL (e.g. `https://us1-abc-12345.upstash.io`). In the Headers section, add: Key = `Authorization`, Value = `Bearer YOUR_REST_TOKEN_HERE`. Paste your actual REST token. Now add individual API Calls for each Redis command you need. Start with GET: Click '+ Add' inside the Upstash group. Name it 'GetKey'. Set Method to GET and URL to `/get/{{key}}`. Add a Variable named `key` (String). In the Response & Test tab, add a JSON Path `$.result` named `value` — Upstash always wraps the result in `{"result": ...}`. Test with a key name and you'll see `{"result": null}` for a non-existent key. Add another API Call named 'SetKey'. Method GET (Upstash REST uses GET for all commands via URL paths, not just reads). URL = `/set/{{key}}/{{value}}`. Add variables `key` and `value` (both String). To set an expiry in seconds, add an optional `ex` variable and use the URL `/set/{{key}}/{{value}}?ex={{ex}}`. The response is `{"result":"OK"}`. Add 'IncrKey': Method GET, URL = `/incr/{{key}}`. This increments the integer at the key by 1 and returns the new value in `$.result`. Useful for counters and rate limits.

1// Upstash REST API Call configurations
2
3// GET a value:
4// GET https://{db}.upstash.io/get/{key}
5// Response: { "result": "cached_value" } or { "result": null }
6
7// SET a value with 1-hour TTL:
8// GET https://{db}.upstash.io/set/{key}/{value}?ex=3600
9// Response: { "result": "OK" }
10
11// INCR a counter:
12// GET https://{db}.upstash.io/incr/{key}
13// Response: { "result": 5 }  // new counter value
14
15// JSON Path to extract the result:
16// $.result

Now that the Upstash API Group is set up, use it to cache expensive or rate-limited API calls. The pattern is: check the cache first, return cached data if found, call the real API if not found, and store the result in cache before returning it to the UI. In the Action Flow Editor, add the following sequence to your data-fetching action: First, call 'Upstash → GetKey' with a key like `weather_london`. Store the `$.result` in a Page State variable called `cachedWeather`. Add a Conditional Action — if `cachedWeather` is not null and not empty, bind the UI directly to `cachedWeather` and end the action flow. If `cachedWeather` is null, continue to the real API call. After the real API call returns data, add two more actions: bind the API response to your UI widgets, then call 'Upstash → SetKey' with the key `weather_london`, the value set to the serialised API response (convert the response to a JSON string), and the expiry (`ex` variable) set to `3600` for a 1-hour cache. Next time a user opens the screen within that hour, the first GetKey call returns the cached value and the real API call is skipped. This pattern dramatically reduces the number of calls to rate-limited APIs and speeds up screen load time — instead of waiting for a network call to an external API, the Redis GET returns in under 50ms (assuming a nearby Upstash region). It also reduces costs on APIs that charge per call.

Redis's INCR command atomically increments an integer stored at a key, returning the new value. This is perfect for rate-limit counters and submission counts. Because Upstash handles the increment server-side and returns the new value in a single round-trip, there is no race condition — multiple users incrementing the same key get consistent results. For a per-user submission counter: when the user taps Submit, call 'Upstash → IncrKey' with the key `submit:{userId}` (use the logged-in user's ID as part of the key to keep counts separate per user). Parse the `$.result` number from the response. Add a Conditional Action — if the result is greater than your allowed limit (e.g. 5), show an error message and stop the form submission. If within the limit, proceed with the form submission action. For the key to reset automatically every hour, you also need to set an expiry. Since Upstash INCR doesn't accept an EX parameter directly, use INCR first, then add a second action that calls 'Upstash → SetKey' with the same key, the same value (the incremented count), and `ex=3600`. This sets the TTL only if the key didn't already have one — the TTL persists across increments within the window. For more complex rate-limiting patterns (sliding window, burst limits), consider handling the logic in a Firebase Cloud Function that performs multiple Redis operations atomically using Upstash's Redis pipeline or Lua scripting — but for most FlutterFlow apps, the simple INCR + EX pattern is sufficient.

Two things to watch when working with Upstash REST from FlutterFlow: URL-encoding of key values, and keeping destructive commands server-side. URL encoding: Upstash REST embeds key names and values directly in URL paths (e.g. `/get/mykey` or `/set/mykey/myvalue`). If your key contains slashes, spaces, colons, or special characters, the URL path breaks and you get incorrect results or 404 errors. Always URL-encode key and value strings before passing them to the Upstash API Calls. In FlutterFlow, you can use a Custom Function or ensure your key naming convention avoids special characters. A safe key naming pattern: use colons for namespacing (`cache:weather:london`) and underscores for spaces (`user_123`). Destructive commands: The REST token you put in the FlutterFlow API Group gives full access to your database. This means a user who decompiles your APK can call `FLUSHALL` and wipe your entire Redis database, or `DEL` any key. For commands that delete data, route them through a Firebase Cloud Function that validates the request (checks that the user is authenticated and authorised to delete that specific key) before executing the command via Upstash's REST API from server-side code. For your FlutterFlow client token, the safe operations are GET, SET (with values), and INCR — all of these have bounded impact. A user who writes to a key they shouldn't can only pollute their own cache entries if your key naming scheme includes their user ID. Design your key namespace with this constraint in mind. If you'd rather have RapidDev's team help architect a more complex Redis caching layer for your FlutterFlow app, we offer free scoping calls at rapidevelopers.com/contact.