AI & API access

TaskFlow can be driven by external tools: connect an AI assistant over the Model Context Protocol (MCP), or call the API from your own scripts. Both use a personal API token.

Get a token

Create a token on your profile page (see Profile & security):

• Choose a scope: full access (everything you can do — API and MCP), read-only (MCP read tools only) or configurator (administrative MCP tools only — see The AI configurator).
• Choose an expiry: 30 days, 90 days, 1 year, or never.
• The token is shown once — copy it then.

A token acts as you, with your permissions. For automation, ask an administrator to create a bot account and issue a token to it, so the integration doesn't break when a person leaves.

Connect an AI assistant (MCP)

The Model Context Protocol lets an AI client work with your tracker as a set of tools — searching, creating and updating issues from your assistant.

Point your client at your instance's /mcp endpoint with your token. For example, with Claude:

claude mcp add --transport http taskflow https://<your-host>/mcp \
  --header "Authorization: Bearer tfp_..."

Any MCP-capable client works the same way: the URL https://<your-host>/mcp and an Authorization: Bearer tfp_... header.

Available tools

Tool	Access	What it does
me	read	Who the token belongs to
list_projects	read	List projects you can see
search_users	read	Find users
list_sprints	read	List a project's sprints
list_boards	read	List a project's boards
search_issues	read	Search issues
get_issue	read	Fetch one issue with comments and available transitions
create_issue	write	Create an issue
update_issue	write	Update an issue
transition_issue	write	Move an issue to another status
add_comment	write	Comment on an issue

Only the read tools are available with a read-only token — or on an instance where an administrator has switched the write tools off. Administrators can also disable the endpoint entirely, and every call is recorded in a journal they can review. See Features & settings → AI & API control.

The AI configurator

A separate set of tools lets an assistant set the system up for your company — not work on issues, but shape the structure: which features are enabled, priorities and issue types, statuses and transitions, roles and permission schemes, groups, projects, user accounts, mail and storage assignments, automation rules, Service Desk request types and queues, custom fields, SLA policies, single sign-on providers. One tool returns a snapshot of the whole current configuration — usually where an assistant starts.

The configurator is deliberately kept apart from everyday work:

• it needs a token with the configurator scope, and only an admin can issue one;
• such a token sees only the administrative tools — issues, comments and the API are closed to it, and an ordinary token sees no administrative tools at all;
• nothing deletes: the configurator can create and update, never remove;
• an administrator can switch this whole circuit off with a single toggle, leaving everyday assistant use untouched.

These are real changes to your instance

An assistant holding this token changes configuration exactly as an administrator would by hand: enabling features, rewriting workflows, granting roles. Keep such tokens short-lived, revoke them once the setup is done, and review what changed in the audit log.

What the assistant can actually do

A token never grants more than its owner has. An assistant connected with your token sees your projects and no others — so if it reports that a project doesn't exist, check your own access first.

Use the API from scripts

A full access token works directly against the GraphQL API at https://<your-host>/graphql. Send it as a bearer token:

curl https://<your-host>/graphql \
  -H "Authorization: Bearer tfp_..." \
  -H "Content-Type: application/json" \
  -d '{"query":"{ me { email } }"}'

From there you can query and mutate the same data you can reach in the app — projects, issues, comments, transitions and more. Read-only and configurator tokens are limited to MCP and cannot use this endpoint.

The API enforces query-complexity limits to protect the server: depth up to 12, up to 2000 nodes and up to 200 aliases. The values suit normal use; they can only be changed through environment variables at deploy time.

Outgoing webhooks

To push events out of TaskFlow, an administrator configures outgoing webhooks: a URL, the event types you care about, and a shared secret, with a delivery log and a test button. Automation rules can also call a webhook as an action.

Link issues to your git hosting

With the dev links feature enabled, TaskFlow shows branches and commits on the issue they belong to. It reads the issue key (for example TF-123) from the branch name and commit messages, so the convention is all your team has to follow.

Setting it up is an administrator task: enable the feature, make the receiving endpoint reachable from your git hosting, and configure the webhook on the GitHub, GitLab or Bitbucket side. Until the endpoint is published, events never arrive and the panel stays empty.

Security notes

• Treat tokens like passwords — store them in a secret manager.
• Use the narrowest permissions that work, and prefer a real expiry over "never".
• Revoke tokens you no longer use; revocation is immediate.
• Use a bot account for shared automation, not a personal one.

Where to go next

• Profile & security — issue and manage tokens.
• Features & settings — administrators control the MCP endpoint and features.
• Automation — react to events inside TaskFlow.