Asana

Navigate to asana.com/0/my-apps in your browser. This is Asana's developer portal where you manage personal access tokens and OAuth apps. Click New Access Token, give it a label like 'FlutterFlow integration', and click Create. Copy the token immediately — Asana only shows it once at creation time. The personal access token (PAT) works for all Asana REST v1 endpoints and is tied to your individual account. It supports up to 1,500 requests per minute for PATs (compared to 150/minute for OAuth apps). This generous limit means most FlutterFlow apps won't hit rate limits unless they fan out across many projects simultaneously. The PAT inherits your account's permissions — it can access every workspace, project, and task you can see in Asana. This means it's a broadly scoped credential. For read-only FlutterFlow features (browsing tasks and projects), storing it in App Constants is reasonable. For write operations like creating or completing tasks, route those through a backend proxy to prevent the token from being extractable from the compiled app. Also note: PATs don't expire by default, but you can revoke them at any time from asana.com/0/my-apps. If you suspect the token has been exposed, revoke it immediately and generate a new one.

In FlutterFlow, click API Calls in the left navigation sidebar. Click + Add → Create API Group. Name the group Asana. Set the Base URL to https://app.asana.com/api/1.0 — this is the base for all Asana REST v1 endpoints. No trailing slash. Add the group-level Authorization header. In the Headers section, click Add Header. Set the key to Authorization and the value to Bearer YOUR_PAT — replace YOUR_PAT with your actual token. Alternatively, go to Settings → App Values (App Constants), create a constant named ASANA_TOKEN with your token value, and set the header to Bearer {{ASANA_TOKEN}} to keep the token in one configurable place. All child API Calls inside this group will inherit this Authorization header automatically. You'll never need to set it on individual calls. Save the group. Now you have a base configuration that all Asana calls will share. The next step is to make your first API call to discover workspace GIDs — Asana's way of identifying objects.

1// API Group configuration reference
2// Group name: Asana
3// Base URL: https://app.asana.com/api/1.0
4// Headers (inherited by all child calls):
5// Authorization: Bearer {{ASANA_TOKEN}}
6// Accept: application/json

Asana identifies every object — workspaces, projects, tasks, users — by an opaque GID (Global ID) string, not by name. Before you can fetch tasks from a specific project, you need the project's GID. The cleanest approach is to fetch it once via API and store it in App State. Add a new API Call inside the Asana group. Name it GetWorkspaces. Method: GET. Endpoint: /workspaces?opt_fields=name,gid. Test this call — you'll see a response like { "data": [{ "gid": "1234567890", "name": "My Workspace" }] }. Note the .data envelope. Copy the GID of your target workspace from the test response. Next, add another API Call. Name it GetProjects. Method: GET. Endpoint: /projects?workspace={{workspaceGid}}&opt_fields=name,gid. Add a variable named workspaceGid. Test it with your workspace GID — you'll see all projects in that workspace. In your FlutterFlow app, create an App State variable named currentWorkspaceGid (String) and another named currentProjectGid (String). On your home page, add a page-load action that calls GetWorkspaces, then sets currentWorkspaceGid from the first item's GID ($.data[0].gid). If the user might have multiple workspaces, build a picker page. Similarly, set currentProjectGid when the user selects a project. By storing GIDs in App State, you avoid re-fetching parent objects every time the user navigates between pages — a common source of unnecessary API calls.

1// GET /workspaces response structure
2{
3  "data": [
4    {
5      "gid": "1234567890123456",
6      "name": "My Company Workspace",
7      "resource_type": "workspace"
8    }
9  ]
10}
11// JSON Path for GID: $.data[0].gid
12// JSON Path for name: $.data[0].name
13
14// GET /projects?workspace={gid} response structure
15{
16  "data": [
17    {
18      "gid": "9876543210987654",
19      "name": "Mobile App Redesign",
20      "resource_type": "project"
21    }
22  ]
23}
24// JSON Path for list: $.data[*].gid and $.data[*].name

Now add the core API Call. Name it GetTasks. Method: GET. Endpoint: /tasks?project={{projectGid}}&opt_fields=name,due_on,assignee.name,completed,notes. Add a variable named projectGid of type String. The opt_fields parameter is critical. Without it, Asana returns only { "gid": "...", "name": "..." } for each task — every other field (due_on, assignee, completed, notes) will be completely absent from the response. There's no error; the fields are just not there. Binding $.data[*].due_on to a Text widget will show nothing, silently. Always include every field you plan to display in opt_fields. Go to the Response & Test tab. Set the projectGid variable to your project GID and click Test API Call. You should see tasks with the requested fields. Click Generate from Response to create JSON Paths. Key JSON Paths to map (note the $.data[*] prefix, not $[*]): - Task name: $.data[*].name - Due date: $.data[*].due_on - Assignee: $.data[*].assignee.name - Completed: $.data[*].completed (boolean) - Task GID: $.data[*].gid On your tasks page in FlutterFlow, add a ListView. Set its Backend Query to the Asana group → GetTasks, passing currentProjectGid from App State as the projectGid variable. Inside the ListView, add Card and Text widgets, binding each to the appropriate JSON Paths. For the due date, bind $.data[*].due_on — guard it with a conditional because tasks without a due date will have null here.

1// GET /tasks request — opt_fields is REQUIRED
2// GET /tasks?project={projectGid}&opt_fields=name,due_on,assignee.name,completed,notes,gid
3
4// Sample response (paste into Response & Test → Generate from Response)
5{
6  "data": [
7    {
8      "gid": "1234567890",
9      "name": "Write onboarding copy",
10      "due_on": "2026-07-15",
11      "completed": false,
12      "notes": "Review with marketing before finalizing",
13      "assignee": {
14        "gid": "9876543210",
15        "name": "Jane Doe"
16      },
17      "resource_type": "task"
18    },
19    {
20      "gid": "1234567891",
21      "name": "Design login screen",
22      "due_on": null,
23      "completed": true,
24      "notes": "",
25      "assignee": null
26    }
27  ]
28}
29
30// Key JSON Paths
31// $.data[*].name        → task name
32// $.data[*].due_on      → due date (string YYYY-MM-DD, can be null)
33// $.data[*].assignee.name → assignee (can be null if unassigned)
34// $.data[*].completed   → boolean
35// $.data[*].gid         → task GID (needed for updates)

Completing a task requires a PUT request to /tasks/{gid} with a body of {"data":{"completed":true}}. Creating a task requires a POST to /tasks with a body containing workspace GID, name, assignee, and project. Both are write operations. For an app with a small, trusted user base (e.g., an internal tool where users log in with your company Asana accounts), you might accept the security trade-off and make these calls directly from FlutterFlow. For consumer-facing apps, route writes through a Firebase Cloud Function or Supabase Edge Function to protect the PAT. If you're making direct FlutterFlow calls, add a CompleteTask API Call in the Asana group. Method: PUT. Endpoint: /tasks/{{taskGid}}. Add a taskGid variable. Set the body to {"data": {"completed": true}}. In your task ListView, add a Checkbox or IconButton to each task row. Wire its Action to Backend/API Call → CompleteTask, passing the current row's $.data[*].gid as taskGid. After a successful response, trigger a page refresh (or update the local App State to reflect the completion without a full refresh, for a snappier UX). For task creation, build a bottom sheet or new page with text fields for task name and due date. POST to /tasks with a body: {"data": {"name": "{{taskName}}", "projects": ["{{projectGid}}"], "workspace": "{{workspaceGid}}", "due_on": "{{dueDate}}", "assignee": "me"}}. The word 'me' in the assignee field automatically assigns to the token owner. Be mindful of the 1,500 req/min rate limit if you have many simultaneous users. If your app powers a team of 20 people all checking tasks at once, you may be sending 20 requests per page load — still well within limits for most team sizes.

1// PUT /tasks/{taskGid} — mark task complete
2// Method: PUT
3// Endpoint: /tasks/{{taskGid}}
4// Body:
5{
6  "data": {
7    "completed": true
8  }
9}
10
11// POST /tasks — create a new task
12// Method: POST
13// Endpoint: /tasks
14// Body:
15{
16  "data": {
17    "name": "{{taskName}}",
18    "notes": "{{taskNotes}}",
19    "due_on": "{{dueDate}}",
20    "projects": ["{{projectGid}}"],
21    "workspace": "{{workspaceGid}}",
22    "assignee": "me"
23  }
24}
25// Note: all body values are also wrapped in the 'data' envelope for writes