How to Integrate Lovable with Asana

Asana personal access tokens (PATs) give server-side access to the Asana workspace on behalf of the token owner. Unlike OAuth2 tokens, PATs don't expire and don't require a redirect flow — they're ideal for server-to-server integrations where your app accesses your own Asana workspace. To generate one, log into Asana and navigate to app.asana.com/0/my-apps (or click your profile photo in the top-right corner, then select 'My Settings', then the 'Apps' tab, then 'Manage Developer Apps'). Click 'Create new token', give it a name like 'Lovable Integration', and copy it immediately — Asana shows the token only once. With your token copied, open your Lovable project and access the Cloud tab by clicking '+' at the top of the screen. Scroll to the Secrets panel and click 'Add secret'. Enter ASANA_ACCESS_TOKEN as the name and paste your token as the value. Click Save. Lovable encrypts this immediately — it will only be accessible from your Edge Functions via Deno.env.get('ASANA_ACCESS_TOKEN') and never from any client-side code. Asana PATs have full read-write access to the token owner's workspace, so treat this credential with the same care as a password.

The Asana REST API v1 is one of the most developer-friendly project management APIs available. All resources use consistent patterns: GET requests with optional opt_fields query parameters to control returned data, POST requests to create resources, PUT requests to update them, and DELETE for removal. The opt_fields parameter is particularly important for performance — without it, list operations return only GID and resource_type, requiring additional requests for each item. The Edge Function below handles the most common Asana operations through an action-based routing pattern. It supports fetching workspaces, projects, sections, and tasks — including tasks with custom field values. The custom fields response requires special handling since Asana returns all custom fields defined in the workspace for each task, and you need to match the field GID to find the value you care about. The function also handles task creation with custom field values, which requires a custom_fields object mapping field GIDs to their values.

1// supabase/functions/asana-proxy/index.ts
2import { serve } from "https://deno.land/std@0.168.0/http/server.ts";
3
4const BASE = "https://app.asana.com/api/1.0";
5const corsHeaders = {
6  "Access-Control-Allow-Origin": "*",
7  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
8};
9
10serve(async (req) => {
11  if (req.method === "OPTIONS") {
12    return new Response("ok", { headers: corsHeaders });
13  }
14  const token = Deno.env.get("ASANA_ACCESS_TOKEN");
15  if (!token) {
16    return new Response(JSON.stringify({ error: "ASANA_ACCESS_TOKEN not set" }), {
17      status: 500, headers: { ...corsHeaders, "Content-Type": "application/json" },
18    });
19  }
20  const auth = { Authorization: `Bearer ${token}`, "Content-Type": "application/json" };
21  const { action, params = {} } = await req.json();
22  let resp;
23  switch (action) {
24    case "list_workspaces":
25      resp = await fetch(`${BASE}/workspaces`, { headers: auth });
26      break;
27    case "list_projects": {
28      const q = new URLSearchParams({ workspace: params.workspaceGid, opt_fields: "name,gid,color,current_status" });
29      resp = await fetch(`${BASE}/projects?${q}`, { headers: auth });
30      break;
31    }
32    case "list_sections":
33      resp = await fetch(`${BASE}/projects/${params.projectGid}/sections?opt_fields=name,gid`, { headers: auth });
34      break;
35    case "list_tasks": {
36      const optFields = params.optFields || "name,gid,completed,due_on,assignee.name,custom_fields";
37      const base = params.sectionGid
38        ? `${BASE}/sections/${params.sectionGid}/tasks`
39        : `${BASE}/tasks?project=${params.projectGid}`;
40      resp = await fetch(`${base}&opt_fields=${optFields}`, { headers: auth });
41      break;
42    }
43    case "get_task":
44      resp = await fetch(`${BASE}/tasks/${params.taskGid}?opt_fields=name,completed,due_on,notes,assignee.name,custom_fields,memberships.section.name,permalink_url`, { headers: auth });
45      break;
46    case "create_task":
47      resp = await fetch(`${BASE}/tasks`, {
48        method: "POST", headers: auth,
49        body: JSON.stringify({
50          data: {
51            name: params.name, notes: params.notes, due_on: params.dueOn,
52            projects: [params.projectGid],
53            ...(params.sectionGid && { memberships: [{ project: params.projectGid, section: params.sectionGid }] }),
54            ...(params.customFields && { custom_fields: params.customFields }),
55          }
56        })
57      });
58      break;
59    case "update_task":
60      resp = await fetch(`${BASE}/tasks/${params.taskGid}`, {
61        method: "PUT", headers: auth,
62        body: JSON.stringify({ data: params.updates })
63      });
64      break;
65    case "complete_task":
66      resp = await fetch(`${BASE}/tasks/${params.taskGid}`, {
67        method: "PUT", headers: auth,
68        body: JSON.stringify({ data: { completed: true } })
69      });
70      break;
71    default:
72      return new Response(JSON.stringify({ error: `Unknown action: ${action}` }), {
73        status: 400, headers: { ...corsHeaders, "Content-Type": "application/json" },
74      });
75  }
76  const data = await resp.json();
77  return new Response(JSON.stringify(data), {
78    status: resp.status, headers: { ...corsHeaders, "Content-Type": "application/json" },
79  });
80});

Asana tasks can carry rich metadata through custom fields — text fields, number fields, enum (dropdown) fields, multi-enum fields, date fields, and people fields. When you fetch tasks with opt_fields=custom_fields, each task returns a custom_fields array where every entry has a gid (field identifier), name (field display name), type (text_value, number_value, enum_value, etc.), and the corresponding value field. Your frontend needs to iterate this array and render each field type appropriately. The following Lovable prompt generates a task list component that handles custom field rendering. It creates a column-configurable table where users can choose which custom fields to display, sorts tasks by due date, and provides a detail panel that shows all task information when a row is clicked. This pattern works well for teams that have invested in custom fields as their primary metadata layer in Asana.

Creating Asana tasks from a Lovable form requires mapping form field values to Asana custom field GIDs. This is the most complex part of the Asana integration — each custom field in Asana has a unique GID, and when creating a task you must pass a custom_fields object where keys are the field GIDs and values are the field values (for enum fields, the value is the enum option GID, not the display name). The recommended approach is to fetch the project's custom field schema first — available through the project's custom_field_settings endpoint — which returns the field GIDs, names, and for enum fields, the option GIDs and names. Store this schema and use it to build your form fields dynamically. For complex multi-project integrations where different projects have different custom field schemas, RapidDev's team can help design a configuration layer that maps your form fields to the right Asana custom field GIDs across projects.

For apps that need to stay synchronized with Asana in real time — rather than polling on a fixed interval — Asana supports webhooks. You create a webhook subscription via POST to /webhooks, specifying the resource GID (project GID to watch), the target URL (your Edge Function), and the filters (which event types to receive). Asana then POSTs an X-Hook-Secret handshake request to your URL — your Edge Function must echo back this secret in the X-Hook-Secret response header to complete registration. After registration, Asana sends webhook events with a signature in the X-Hook-Signature header. Unlike some platforms, Asana webhook signatures use HMAC-SHA256 and require you to store the X-Hook-Secret from the handshake. Store this value in Cloud Secrets as ASANA_WEBHOOK_SECRET after the initial handshake — your ongoing webhook handler verifies all subsequent events against this secret.