Terraform

Before building anything, it is essential to establish what this integration can and cannot do, because the mismatch between expectation and reality is significant for a tool like Terraform. FlutterFlow is a client-side app builder. When someone searches 'FlutterFlow Terraform integration,' they might imagine FlutterFlow running terraform apply in the cloud. That is not what happens. FlutterFlow compiles to a Flutter app that runs on the user's phone — it has no ability to execute CLI commands, hold .tfstate files, or interact with Terraform providers. HCP Terraform (HashiCorp Cloud Platform Terraform), at https://app.terraform.io/, is the part of the Terraform ecosystem that HAS a REST API your FlutterFlow app can call. HCP Terraform stores your Terraform code in workspaces, runs plans and applies on managed cloud runners, stores state remotely, and exposes a well-documented API for reading and triggering those operations. The Terraform CLI binary itself has no API — it is a local command-line tool. So the integration you are building is: FlutterFlow → HCP Terraform REST API → reads workspace/run data. The app becomes a mobile status reader and optional remote trigger. Actual execution of Terraform runs happens entirely on HCP Terraform's infrastructure — your FlutterFlow app only requests and displays the results. There is an important security consideration as well. HCP Terraform's Organization-level API tokens can apply and destroy live infrastructure. These tokens must NEVER ship inside your FlutterFlow app's compiled code. Read-only User or Team tokens are safer for the dashboard path. For triggering runs, you must route the request through a Firebase Cloud Function that holds the token server-side — covered in Step 4. Decide upfront: read-only dashboard only, or read + trigger runs?

In your FlutterFlow project, click API Calls in the left navigation panel. Click + Add, then select Create API Group. Name the group TerraformCloud and set the Base URL to https://app.terraform.io/api/v2 (no trailing slash). Now add two headers to the group — these will apply to every API Call inside it: 1. Authorization: Bearer {{terraformToken}} — your HCP Terraform API token. You will store the token as an App Constant in Settings & Integrations → App Settings → App Constants; name the constant TERRAFORM_TOKEN and bind the header value to it. 2. Content-Type: application/vnd.api+json — this is the JSON:API content type that HCP Terraform expects. On write operations (POST, PATCH), the HCP Terraform API requires this exact content type header rather than application/json. On GET requests it is also expected. Setting it at the group level covers all calls. Save the group. The two headers are the foundation of every HCP Terraform API call you will make. Getting the Content-Type wrong is one of the most common errors on write calls — it causes 415 Unsupported Media Type responses. Note about the token: an Organization API token gives read and write access to all resources under the organization, including the ability to trigger applies and potentially destroy infrastructure. For a read-only dashboard, use a Team token scoped to specific workspaces with read permissions, or a User token with appropriate access. Store whichever token you choose in the App Constant and never paste it directly into a header value as a hardcoded string.

1// TerraformCloud API Group configuration for FlutterFlow:
2// Base URL: https://app.terraform.io/api/v2
3// Shared headers (set at API Group level):
4
5{
6  "Authorization": "Bearer {{terraformToken}}",
7  "Content-Type": "application/vnd.api+json"
8}
9
10// App Constant setup:
11// Settings & Integrations → App Settings → App Constants
12// Name: TERRAFORM_TOKEN
13// Value: your HCP Terraform API token (team/user token, read scope)
14// Bind the header value to this constant.

Inside the TerraformCloud API Group, click + Add → Create API Call. Name the first call GetWorkspaces and set the method to GET with endpoint /organizations/{{orgName}}/workspaces — replace {{orgName}} with a variable (add it in the Variables tab of the API Call, type: String). This endpoint returns a JSON:API list of all workspaces for your organization. In the Response & Test tab, enter your actual organization name in the orgName variable field and click Test API Call. You should receive a 200 response with a JSON body. Here is where JSON:API nesting matters: the workspace data is NOT at the top level. It lives under data[], and each workspace's fields are under data[].attributes. Click Generate JSON Paths — FlutterFlow will extract paths like: - $.data[0].attributes.name — workspace name - $.data[0].attributes.description — workspace description - $.data[0].attributes.terraform-version — Terraform version in use - $.data[0].id — workspace ID (needed for subsequent calls) Add a second API Call named GetWorkspaceRuns with GET /workspaces/{{workspaceId}}/runs. Add a workspaceId variable (String). Test it with one of the workspace IDs you retrieved from the first call. The runs response also follows JSON:API; JSON Path $.data[0].attributes.status gives you the latest run status (possible values: pending, plan_queued, planning, planned, applying, applied, errored, canceled, force_canceled, policy_checked, policy_override). Add a third API Call named GetRunDetails with GET /runs/{{runId}} for a single run's full details, including $.data.attributes.status, $.data.attributes.status-timestamps.applied-at, and $.data.attributes.message. Now bind the workspace list to a screen. Create a Page with a Backend Query using GetWorkspaces (bind orgName to your App Constant or a hardcoded Page Parameter). Add a ListView component and set its data source to the query result — each list item shows the workspace name and a status badge derived from the current run status.

1// JSON Path reference for HCP Terraform JSON:API responses
2// API Group: TerraformCloud
3
4// GET /organizations/{{orgName}}/workspaces
5// Workspace list paths:
6//   $.data[0].id                               — workspace ID
7//   $.data[0].attributes.name                  — workspace name
8//   $.data[0].attributes.description           — description
9//   $.data[0].attributes.terraform-version     — TF version
10//   $.data[0].attributes['resource-count']     — managed resource count
11//   $.data[0].attributes['updated-at']         — last updated timestamp
12
13// GET /workspaces/{{workspaceId}}/runs
14// Run list paths:
15//   $.data[0].id                               — run ID
16//   $.data[0].attributes.status                — run status string
17//   $.data[0].attributes.message               — commit message / trigger
18//   $.data[0].attributes['created-at']         — run created timestamp
19//   $.data[0].attributes['status-timestamps']['applied-at'] — apply time
20
21// GET /runs/{{runId}}
22// Single run paths:
23//   $.data.id
24//   $.data.attributes.status
25//   $.data.attributes.message
26//   $.data.attributes['has-changes']           — boolean: plan found changes

If you want a 'Trigger Plan' button in your FlutterFlow app that creates a new HCP Terraform run for a workspace, you must route that request through a backend proxy. Creating a run requires a POST to /runs with an Organization or Team token that has write permissions — and that token can trigger apply operations that create, modify, or destroy real cloud infrastructure. Shipping it in client Dart would be a critical security risk. The pattern: deploy a Firebase Cloud Function that receives the workspace ID and run type from FlutterFlow, holds the HCP Terraform write token as an environment variable, and POSTs to the HCP Terraform /runs endpoint using the JSON:API format. FlutterFlow calls your Cloud Function URL instead of the Terraform API directly. In Firebase Console → Functions → create a new Node.js function. Store the HCP Terraform org token in Firebase environment config or Secret Manager (never in function source code). The function constructs a JSON:API run-creation body and POSTs it to https://app.terraform.io/api/v2/runs with the correct Content-Type: application/vnd.api+json header. Once deployed, note your Cloud Function URL. Back in FlutterFlow, create a new API Group called TerraformProxy pointing at your Cloud Function base URL, or add a single API Call to an existing group for the trigger action. Wire it to a Button widget using the Action Flow Editor: button → Actions → + Add Action → Backend Call → select the trigger API Call → pass the workspaceId as a variable → on success, show a SnackBar confirming the run was queued. Add a confirmation AlertDialog before the action fires — triggering a plan/apply on a production workspace is not reversible. Gate the button with a confirmation step: 'Are you sure you want to trigger a Terraform plan on production?' If you would rather skip building the proxy yourself, RapidDev's team handles FlutterFlow integrations like this every week — free scoping call at rapidevelopers.com/contact.

1// Firebase Cloud Function — HCP Terraform run trigger proxy (Node.js)
2const functions = require('firebase-functions');
3const fetch = require('node-fetch');
4
5exports.triggerTerraformRun = functions.https.onRequest(async (req, res) => {
6  res.set('Access-Control-Allow-Origin', '*');
7  if (req.method === 'OPTIONS') { res.status(204).send(''); return; }
8
9  const terraformToken = process.env.TERRAFORM_ORG_TOKEN;
10  const { workspaceId, message } = req.body;
11
12  if (!workspaceId) {
13    return res.status(400).json({ error: 'workspaceId is required' });
14  }
15
16  const runPayload = {
17    data: {
18      type: 'runs',
19      attributes: {
20        message: message || 'Triggered from FlutterFlow app',
21        'plan-only': true  // set to false to allow apply after plan
22      },
23      relationships: {
24        workspace: {
25          data: { type: 'workspaces', id: workspaceId }
26        }
27      }
28    }
29  };
30
31  const response = await fetch('https://app.terraform.io/api/v2/runs', {
32    method: 'POST',
33    headers: {
34      'Authorization': `Bearer ${terraformToken}`,
35      'Content-Type': 'application/vnd.api+json'
36    },
37    body: JSON.stringify(runPayload)
38  });
39
40  const data = await response.json();
41  res.status(response.status).json(data);
42});