Pingdom

Log in to your Pingdom account at my.pingdom.com. In the top-right account menu click Settings, then navigate to the Pingdom API section. Click the Generate API Token button and give it a descriptive name like 'FlutterFlow Dashboard'. Copy the token immediately and store it in a secure location such as a password manager—Pingdom will not show the full token again after you navigate away. Before you leave the Pingdom dashboard, take note of the numeric Check IDs for any monitors you want to display in your app. You can find the ID by clicking on a check in the left panel and reading the number from the URL (e.g., /checks/12345678). You will need these IDs when building the detail and summary calls in FlutterFlow. Pingdom API tokens carry full read access across your entire account, including all checks, alert contacts, users, and historical data. For a dashboard app this is acceptable, but keep in mind this is not a scoped token—it is equivalent to a read-everything credential. Treat it with the same care as a password: do not share it, do not put it in source code, and do not paste it into any field that will compile into your Flutter app bundle. The only safe place in FlutterFlow is the API Group header, which is configured at build time and not exposed through Custom Action Dart.

In FlutterFlow, click API Calls in the left navigation panel. Click the + Add button and choose Create API Group. Name the group Pingdom and set the Base URL to https://api.pingdom.com/api/3.1. Do not include a trailing slash. With the API Group selected, click the Headers tab. Add a new header with the name Authorization and the value Bearer YOUR_TOKEN—replacing YOUR_TOKEN with the actual token string you generated in step 1. This header will be inherited by every API Call you add inside this group, so you configure authentication exactly once at the group level. Why the API Group header and not a Custom Action variable? When you set the token in the API Group header, FlutterFlow stores it in its project configuration at build time. It is not placed inside the Dart code that gets compiled into your app binary. By contrast, if you were to reference a token string inside a Custom Action (Dart code), that string would be compiled directly into the app bundle that ships to every user's device—where it can be extracted with basic tools. The API Group header approach is not perfectly secure for all threat models, but it is the most appropriate client-side approach for a read-only monitoring dashboard. Once you have set the header, click Save. The Pingdom group now appears in your API Calls list.

1{
2  "group_name": "Pingdom",
3  "base_url": "https://api.pingdom.com/api/3.1",
4  "headers": {
5    "Authorization": "Bearer YOUR_PINGDOM_API_TOKEN"
6  }
7}

Inside the Pingdom API Group, click + Add API Call. Name this call Get All Checks, set the HTTP method to GET, and set the endpoint path to /checks. Leave the request body empty—this is a plain GET request. Click Save. Next, add a second API Call named Get Uptime Summary. Set method to GET and endpoint to /summary.average/{checkid}. Go to the Variables tab and add a variable named checkid (type String). FlutterFlow will substitute {{ checkid }} in the endpoint path at runtime. Also add optional query variables: from (Unix timestamp for period start) and to (Unix timestamp for period end), both as String variables with empty defaults. Click Save. Optionally add a third call named Get Outage Windows at /summary.outage/{checkid} with the same checkid variable pattern. Now test your calls. Select the Get All Checks call and click the Test tab. You do not need to fill in any variables—this call uses only the shared Authorization header from the group. Click Send. You should receive a JSON response containing an array of check objects under the key checks. If you get a 401, double-check the token value in the group header for extra spaces or missing 'Bearer ' prefix. If you get a 403, your token may have been rotated or deleted in Pingdom. Once you see a successful response, click Generate JSON Paths—FlutterFlow will parse the response structure and offer paths like $.checks[0].name, $.checks[0].status, $.checks[0].hostname, and $.checks[0].lasttesttime.

1// Example successful GET /checks response (partial)
2{
3  "checks": [
4    {
5      "id": 12345678,
6      "name": "My Production API",
7      "type": "http",
8      "lasttesttime": 1720512000,
9      "status": "up",
10      "resolution": 5,
11      "hostname": "api.myproduct.com",
12      "use_legacy_notifications": false,
13      "created": 1700000000
14    }
15  ],
16  "counts": { "total": 3, "limited": 3, "filtered": 3 }
17}
18
19// Useful JSON Paths:
20// $.checks[:].id           → list of check IDs
21// $.checks[:].name         → list of check names
22// $.checks[:].status       → 'up' | 'down' | 'paused'
23// $.checks[:].hostname     → hostname being monitored
24// $.checks[:].lasttesttime → Unix timestamp of last test

To make the API response easy to work with throughout your app, define a custom Data Type in FlutterFlow. Go to the Data Types panel (left nav → Data Types → + Add Data Type). Name it PingdomCheck and add the following fields: id (Integer), name (String), status (String), hostname (String), and lastTestTime (Integer). Next, build your status screen. Add a ListView widget to your screen. In the Actions panel for the page, add a Backend/API Call action that fires on page load, targeting your Get All Checks call. Enable Refresh Page Load so data loads when the screen opens. Select the ListView widget. Under Backend Query, set it to call your Pingdom API Group → Get All Checks and map the response using the JSON Paths you generated. Map $.checks[:].id to id, $.checks[:].name to name, $.checks[:].status to status, and so on. Inside the ListView, add a Card widget for each row. Place a Text widget bound to item.name for the check name. Add a Container widget with a ConditionalValue on its background color: if item.status equals 'up', use green (#4CAF50); if it equals 'down', use red (#F44336); otherwise use grey (#9E9E9E). This gives your users an immediate visual signal of which monitors are healthy. To support pull-to-refresh, wrap your ListView in a RefreshIndicator widget (available under the Layout Elements section in FlutterFlow). Wire the onRefresh callback to trigger the Get All Checks API Call again. This way users can manually reload data without setting an aggressive automatic timer that might hit Pingdom's rate limits. For the detail screen, create a new page and pass the check id as a parameter when the user taps a card. On that page, call Get Uptime Summary with the checkid parameter to show the average uptime percentage.

On your check detail screen, you want to show the 7-day or 30-day uptime percentage from GET /summary.average/{checkid}. Add a page parameter to this screen called checkId (String). On page load, trigger a Backend/API Call action for Get Uptime Summary, passing the checkId page parameter into the checkid variable. The response from /summary.average looks like this: { "summary": { "responsetime": { "avgresponse": 245 }, "status": { "totalup": 598500, "totaldown": 1200, "totalunknown": 0 } } }. You can calculate uptime percentage yourself: totalup / (totalup + totaldown + totalunknown) * 100. In FlutterFlow, use a Custom Function (left nav → Custom Code → + Add → Function) to perform this calculation. The Dart function takes three integer arguments and returns a double. Bind the return value to a Text widget formatted as a percentage. For rate limiting, Pingdom sends back Req-Limit-Short and Req-Limit-Long headers with each response indicating how many requests remain in the short-window and long-window periods (check your Pingdom plan documentation for the exact limits). FlutterFlow doesn't surface response headers natively in the UI, but the practical rule is: do not schedule automatic refreshes on a timer shorter than 60 seconds, and prefer on-demand refresh so the user controls when a network call happens. If you see a 429 Too Many Requests response, show the user a 'Too many requests—try again in a moment' message rather than retrying automatically. If you later want real-time push notifications when a monitor goes down, you will need a Firebase Cloud Function that receives Pingdom's outgoing webhook alerts and sends an FCM push notification to your app. That is a separate integration beyond this dashboard scope—but this read-only polling approach is a solid starting point for most founder use cases.

1// Custom Function: calculateUptimePercentage
2// Add this in FlutterFlow → Custom Code → + Add → Function
3// Dependencies: none
4
5double calculateUptimePercentage(
6  int totalUp,
7  int totalDown,
8  int totalUnknown,
9) {
10  final total = totalUp + totalDown + totalUnknown;
11  if (total == 0) return 0.0;
12  return (totalUp / total) * 100;
13}