Asana is the de facto task management tool for cross-functional product, marketing, and operations teams. It is opinionated, fast, and almost every B2B team has at least one workspace running. The problem is the same as with any tool that humans run by hand: as the volume grows, manual handling stops scaling. Updates get missed, tasks stay in "In progress" for weeks, weekly status meetings turn into archaeology.

The fastest way to fix that is to give an AI agent live access to Asana through the official JSON API. In this article, we will walk through the full setup: how to get a Personal Access Token (PAT), how to wire it into OpenClaw, what the JSON API can and cannot do, and what to be careful about. By the end you will have a real, working agent that can read, create, complete, and reassign tasks, manage sections, and run project workflows on your behalf.

This is the fourth article in the "How to connect X to OpenClaw" series. If you have already read How to automate Gmail, Telegram, and Trello, you will notice the pattern: same shape, simpler auth. Asana's auth is even simpler than Trello's — one Personal Access Token instead of an API key + token pair.

What is Asana and what can the API do?

Asana is built around four primitives:

• Workspaces. The top-level container. Most teams have one workspace, larger companies may have several.
• Projects. A project is a collection of tasks organised under a goal. Projects belong to a workspace.
• Sections. A project is divided into sections (columns or stages), for example "Backlog", "In progress", "Done". Sections are optional but very common.
• Tasks. A task is a unit of work inside a project. Tasks have descriptions, assignees, due dates, dependencies, custom fields, attachments, comments, subtasks, and tags.

On top of these, Asana has portfolios (a roll-up of projects), goals (OKRs), forms (intake), rules (triggers), and custom fields. The JSON API exposes most of them.

What the API can do for you:

• read every workspace, project, section, and task the token has access to;
• create, update, complete, delete, and move tasks;
• create, update, and delete projects and sections;
• assign and unassign users;
• post comments and create subtasks;
• set due dates, dependencies, tags, and custom field values;
• subscribe to webhooks for real-time updates;
• search across the workspace.

What the API cannot do, or can do with limits:

• it cannot impersonate other members (you act as the user the token belongs to);
• rate limits apply (around 150 requests per minute per token for free and premium plans, higher for Business and Enterprise — more on this below);
• some advanced features (Portfolios, Goals, Forms, certain custom fields) require paid Asana plans;
• file uploads require a separate two-step process (upload to Asana's CDN, then attach by URL).

Why Asana's JSON API is the right integration path

There are three ways to integrate third-party software with Asana.

1. The official REST API. This is what we will use. It is well-documented, stable, and gives you full access to everything Asana can do. Authentication is via a Personal Access Token, an OAuth flow, or a service account. For agent-style use, PAT is the cleanest.

2. Asana's webhooks. When something changes in Asana (a task is created, a comment is posted, a project is renamed), Asana can POST a payload to a URL you provide. Combined with the API, webhooks let you build real-time agents that react to events instead of polling.

3. Zapier / Make / n8n style middleware. A no-code layer on top of the API. Useful for non-technical users; overkill for an AI agent. The agent can already call tools — it does not need a graphical drag-and-drop in the middle.

For an OpenClaw agent, the JSON API + webhooks is the right shape. The agent calls the API when it needs to read or write, and Asana pushes events back via webhooks when something changes on the Asana side.

What you will build

By the end of this article you will have:

• an Asana Personal Access Token scoped to the workspaces you choose;
• the token stored in OpenClaw's secret manager (never in source);
• an agent that can read, create, complete, and reassign tasks, manage sections, post comments, and react to Asana webhooks;
• a working end-to-end use case — for example, "every new task with tag bug automatically gets a triage comment and an assignee suggestion" or "every Monday at 9 am, post a status summary of the project to Slack".

Total setup time: about 20 minutes. No new infrastructure beyond an OpenClaw account and an Asana workspace.

Step 1: Get an Asana Personal Access Token

The Personal Access Token (PAT) is the modern, recommended way to authenticate an external script or service. It replaces the old "API key" approach that Asana used to expose.

1. Log in to app.asana.com in a browser.
2. Click your profile photo (top right) and open "My Settings" → "Apps" → "Developer apps" (or, depending on your Asana plan, "Personal access tokens" directly).
3. Click "Create new token" (or "New access token").
4. Give it a name you will recognise later — for example, openclaw-agent-prod or openclaw-staging.
5. Asana will show the token exactly once. Copy it and store it somewhere safe. You cannot retrieve it again — only revoke it and create a new one.

The token looks like a long random string, something like 2/12345678901234/12345678901234:abcdef1234567890abcdef1234567890. Treat it like a password. Anyone with the token can act as you in every workspace you have access to.

Important: a PAT inherits the permissions of the user who created it. If you are a workspace admin, the agent can do admin things. If you are a regular member, the agent can only see and do what you can see and do. Choose carefully which user the token belongs to. For most agents, create a dedicated "automation user" with the minimum permissions you actually need.

Step 2: Note your workspace GID

Every Asana object has a globally unique identifier (GID) — a long numeric string. To use the API, you need the GID of the workspace, project, or task you want to operate on.

To find your workspace GID:

1. Open Asana in a browser.
2. Navigate to the workspace you want to automate.
3. Look at the URL. It will look like https://app.asana.com/0/<workspace_gid>/list. The numeric segment is the workspace GID.
4. Alternatively, call the API:

curl -H "Authorization: Bearer YOUR_PAT" https://app.asana.com/api/1.0/workspaces
          

The response is a JSON array of workspaces you have access to. Each has a gid and a name. Pick the one you want to automate and copy its gid.

For projects, the GID is in the URL when you open the project (/0/<workspace_gid>/<project_gid>/...). For tasks, open the task and copy the GID from the URL.

Step 3: Verify the token with a one-liner

Before wiring the token into OpenClaw, verify it works with a simple HTTP call.

curl -H "Authorization: Bearer YOUR_PAT" \
          -H "Accept: application/json" \
          https://app.asana.com/api/1.0/users/me
          

A successful response includes the user the token belongs to, with a gid, name, and email. The email.gid is the user GID you will use for assignee fields.

If the response is a 401, the token is wrong or revoked. If the response is a 403, the token does not have access to the resource. If the response is a 200 with a user object, you are good.

Step 4: Store the token in OpenClaw's secret manager

OpenClaw has a first-class secret store. You never want the PAT in source, in a .env file that gets committed, or in chat.

In the OpenClaw control panel, go to "Settings" → "Secrets" → "Add secret":

• Name: asana_pat (or ASANA_PAT if you prefer the env-var convention).
• Value: the PAT you copied in Step 1.
• Scope: the agent or workspace that needs access. Scope the smallest possible.

OpenClaw stores the secret encrypted at rest, with optional per-agent ACLs. The agent sees a reference ({{secrets.asana_pat}}) in its prompt or tool config, never the raw value.

If you are running OpenClaw self-hosted, the equivalent is openclaw secrets set asana_pat <value> from the CLI. The secrets file lives in ~/.openclaw/secrets/ with chmod 600 and is never checked in.

Step 5: Configure the Asana tool in OpenClaw

OpenClaw ships an asana tool in the default tool registry. You do not need to write any integration code — you just register the tool with the workspace GID you noted in Step 2.

In the OpenClaw UI, go to "Tools" → "Asana" → "Connect":

• Token reference: {{secrets.asana_pat}}.
• Default workspace GID: <the workspace GID from Step 2>.
• Default project GID: (optional) — if you want the agent to default to a specific project, e.g. 1209876543210987.
• Webhook URL: (optional) — if you want Asana to push events to your agent, set this to the URL OpenClaw gave you under "Settings" → "Webhooks" → "Add endpoint". Asana will POST a payload there whenever a task, comment, or project changes.

The tool configuration is stored as JSON. You can also apply it via the CLI:

openclaw tools connect asana \
          --token-ref "{{secrets.asana_pat}}" \
          --default-workspace 123456789012345 \
          --webhook-url https://api.openclaw.com/hooks/asana/<agent-id>
          

After connecting, OpenClaw will run a quick smoke test — it calls /users/me and /workspaces to verify the token and resolve the workspace. If both succeed, the tool is enabled and the agent can start using it.

Step 6: First agent use cases

The agent now has a working asana.* namespace in its tool registry. The available actions include:

• asana.list_tasks — list tasks in a project, section, or assignee queue;
• asana.get_task — get full details of a single task by GID;
• asana.create_task — create a new task in a project or section;
• asana.update_task — change fields on a task (assignee, due date, name, notes, custom fields);
• asana.complete_task — mark a task as completed;
• asana.delete_task — delete a task (soft delete; can be restored from trash);
• asana.move_task — move a task to a different section or project;
• asana.add_comment — post a comment on a task;
• asana.list_projects — list projects in a workspace;
• asana.list_sections — list sections in a project;
• asana.search — full-text search across the workspace;
• asana.subscribe_webhook — programmatically subscribe to Asana events.

The agent can chain these in a single reasoning loop. Six useful patterns to start with:

1. New-task triage. When a task is created with the tag bug or urgent, the agent posts a triage comment asking for repro steps, screenshots, and expected behaviour. It also looks at the task description and suggests an assignee based on past assignments in the same project.

2. Daily standup digest. Every morning at 9 am, the agent scans all tasks assigned to the user that are due today or overdue, and posts a Slack message with a one-line summary per task. The agent can also flag tasks that have been "In progress" for more than 7 days with no comment.

3. Stale-task detector. Once a week, the agent lists all tasks in the "In progress" section of the active project, checks the modified_at field, and flags any task that has not been updated in 14 days. The agent posts a comment on the flagged tasks: "This task has been in progress for N days with no updates. Should it be moved back to Backlog, kept open, or closed?"

4. Auto-subtask creator. When a task is moved into the "In review" section and the description is empty, the agent adds subtasks: "Add screenshots", "Add test plan", "Add acceptance criteria". The agent can also fill the description from a template stored in OpenClaw's prompt.

5. Weekly status report. Every Friday at 4 pm, the agent reads all tasks completed this week, all tasks created this week, and all tasks overdue. It writes a 3-paragraph status report and posts it to the project description (so the project header in Asana always has a fresh summary).

6. Customer-onboarding workflow. When a new customer is added to a CRM (Salesforce, HubSpot, or a webhook from a form), the agent creates a project in Asana with a templated set of tasks: kickoff call, technical setup, training session, 30-day check-in. The agent assigns each task to the right person based on the customer's plan.

All six use cases are first-class agents you can ship in a day each. None of them require custom code beyond the agent's prompt.

Step 7: Real-time via webhooks

Polling is fine for low-frequency agents, but the moment you want real-time, switch to webhooks.

In the OpenClaw UI, copy the webhook URL for your agent (under "Settings" → "Webhooks"). In Asana, go to the project you want to subscribe to → "..." (top right) → "Add webhook" → paste the URL → save. Asana will POST a JSON payload to your URL every time a tracked event happens in that project.

The payload looks like:

{
          "events": [
          {
          "action": "added",
          "resource": { "gid": "1234567890", "resource_type": "task" },
          "user": { "gid": "9876543210", "name": "Alice" }
          }
          ]
          }
          

OpenClaw's webhook handler validates the X-Hook-Secret handshake (Asana uses this to confirm the endpoint), then routes each event to the right agent based on project GID and event type. The agent can then decide: ignore, comment, reassign, escalate, etc.

A common pattern: subscribe to task.added and task.changed events in your "Intake" project. When a new task is added, the agent reads the description, suggests a section based on the content ("this looks like a bug", "this looks like a feature request"), and moves the task. When a task is changed, the agent posts a "change summary" comment if the description was modified.

Step 8: Production patterns and safety

Three things to lock down before you put an agent on a production Asana workspace.

Rate limits. Asana's free and Premium plans have a soft limit of around 150 requests per minute per token. Business and Enterprise are higher. The agent's prompt should include a back-off loop: if it gets a 429 response, it waits 30 seconds and retries. OpenClaw's tool layer already does this automatically for the standard Asana tool, but if you write a custom action, follow the same pattern. Burst behavior (e.g. listing 10,000 tasks in one call) is the fastest way to hit the limit.

Scope creep. A Personal Access Token has the same permissions as the user who created it. If you create the token from your admin account, the agent can delete projects, change workspace settings, and reassign every task in the workspace. For most use cases, create a dedicated "OpenClaw automation" user with Member (not Admin) role, and only add it to the projects it needs to touch.

Auditability. Every action the agent takes goes through the Asana API, and every API call shows up in Asana's own audit log. The agent's prompt should be written so that high-risk actions (delete project, bulk reassign, change workspace settings) require a human confirmation step. OpenClaw's tool layer supports this via confirm: true flags on tool calls — the agent's UI surfaces a confirmation prompt before the call is made.

Comparison: Asana vs Trello (also via OpenClaw)

Asana and Trello overlap heavily but differ in shape. Both are project management tools, both have a JSON API, both can be automated via OpenClaw. The differences that matter for an agent:

• Entity model. Trello has boards, lists, cards. Asana has projects, sections, tasks. Trello's card is a flat unit; Asana's task can have subtasks, dependencies, and custom fields. For an agent that needs to model complex workflows (e.g. "wait for subtask A to complete before subtask B can start"), Asana is the better fit. For an agent that just needs kanban, Trello is simpler.
• Auth. Trello uses an API key + token pair. Asana uses a single Personal Access Token. Asana is slightly simpler.
• Rate limits. Trello: 100 req/10s per token, 300 req/10s per API key. Asana: ~150 req/min per token. Both are generous enough for typical agent workloads.
• Webhooks. Both support webhooks. Trello's payload is slightly simpler; Asana's has more metadata. OpenClaw handles both the same way.
• Custom fields. Both have them, but Asana's are richer (number, enum, date, text, multi-enum). Trello's custom fields require a Power-Up.
• Permissions. Trello is board-scoped (you give access to a board). Asana is workspace-scoped (you give access to a workspace, then project, then task). Trello is easier to lock down; Asana is more flexible.

If you are choosing between the two for a new project, the rule of thumb is: Trello for kanban, Asana for everything else. If you already have a Trello board, stick with Trello. If you have an Asana workspace, stick with Asana. The agent does not care.

FAQ

Is the Personal Access Token the only auth method?

No. Asana also supports OAuth 2.0 (for apps that act on behalf of many users) and service accounts (for apps that need workspace-wide access without a human in the loop). For a single-agent use case, PAT is the cleanest.

Can I rotate the token without breaking the agent?

Yes. Add a new token in Asana, store it in OpenClaw as asana_pat_v2, update the tool config to reference the new name, and remove the old secret. There is no downtime. Asana does not enforce a token lifetime by default; rotation is a hygiene best practice, not a hard requirement.

Does the agent see private tasks I am not a member of?

No. The PAT inherits your visibility. If you cannot see a task in the Asana UI, the agent cannot see it via the API. This is why the choice of "which user the token belongs to" matters.

Can the agent delete a project?

Yes, if the user the token belongs to has delete permissions. Most workspaces restrict project deletion to admins. As a safety pattern, do not give the agent a token from an admin account for routine automation.

What happens if Asana is down?

The agent's tool calls return errors. OpenClaw surfaces the error to the agent, which can either retry with back-off or report the failure to the human. Webhooks from Asana to your agent are queued by Asana and replayed when the endpoint is back online.

Can the agent create subtasks?

Yes. Use asana.create_subtask or set the parent field when calling asana.create_task. The agent can build a full task tree in one reasoning loop.

Can the agent work across multiple Asana workspaces?

Yes, if the user the token belongs to has access to multiple workspaces. The agent just needs to pass the correct workspace or project GID with each call. OpenClaw's tool layer handles routing.

Conclusion

Asana's Personal Access Token makes the auth story simple — one token, scoped to one user, scoped to the workspaces that user can see. The JSON API is well-documented, the rate limits are generous, and webhooks give you real-time event delivery. Combined with OpenClaw's tool layer, you have a working agent in 20 minutes that can triage tasks, post comments, run standups, and write weekly status reports.

The hardest part is not the auth or the API. The hardest part is choosing which user the token belongs to. Get that wrong, and the agent can see and do things it should not. Get it right, and the agent is a quiet, reliable co-worker that handles the routine and escalates the exception.

Read the Trello guide for the kanban equivalent. Read the Telegram guide for the chat channel. Pick the tool that fits the workflow, and the rest is a token, a tool config, and a prompt.

Common pitfalls

• Skipping the planning phase — Teams that jump straight into prompt engineering usually spend weeks rebuilding once they hit edge cases. Spend 30 minutes mapping the trigger, the action, and the fallback before writing the first instruction.
• Treating the first successful run as done — A 90% pass rate still produces 1 wrong answer in 10. Set an explicit acceptance threshold (typically 99% for production) and instrument the agent to log when it falls short.
• Skipping audit logging — If you can't replay what the agent did three weeks ago, you can't debug it, bill it, or trust it. Persist every tool call with timestamps and inputs from day one.
• Replacing project managers instead of augmenting them — PMs who feel replaced by the agent resist it. Frame the agent as the PM's assistant (status reports, standup drafts) and adoption goes 5x faster.

Related articles

• How to automate Trello with OpenClaw
• How to automate Vercel deployments with OpenClaw
• How to automate Slack with OpenClaw
• OpenClaw Skills vs Plugins: The Architectural Fork Beginn...
• How to run autonomous coding tasks in OpenClaw with Codex...