Skip to main content

Scopes

Every operation in the Kanban API requires one of three token scopes. Scopes are chosen when the token is created and are cumulative: kanban:write includes everything kanban:read allows, and kanban:admin includes everything kanban:write allows.

ScopeCapability
kanban:readList and read visible Kanban resources
kanban:writeIncludes read; create and mutate boards, columns, cards, and collaboration resources
kanban:adminIncludes write; manage board membership and visibility and perform permanent deletion

A request whose token lacks the required scope fails with 403 insufficient_scope before any resource is touched.

note

Scopes gate the token, not the user. A scope never grants more than the represented user's own permissions in the web app — a kanban:admin token held by a user who did not create a board still cannot change that board's visibility. The application permission column below is checked in addition to the scope.

Which scope does an operation need?

Every operation's required scope is listed in the API reference. As an orientation:

OperationToken scopeApplication permission
Read account or the workspace member directorykanban:readactive workspace membership
List or read a board and its columns, cards, labels, members, subtasks, comments, attachmentskanban:readboard access
Create a workspace boardkanban:writeactive workspace membership
Edit board name, description, or cover colorkanban:writeboard access
Change board visibilitykanban:adminboard creator
Add or remove explicit board memberskanban:adminboard creator
Permanently delete a boardkanban:adminboard access and either board creator or workspace owner/admin
Create, rename, move, or archive a columnkanban:writeboard access
Create, edit, move, complete, archive, or restore a cardkanban:writeboard access
Permanently delete a cardkanban:adminboard access
Create or delete a labelkanban:writeboard access
Assign users, apply labels, manage subtaskskanban:writeboard access; target user/label must belong to the board scope
Create commentskanban:writeboard access
Edit or delete commentskanban:writeboard access and comment author
Attach/detach files, set/clear coverkanban:writeboard access and current access to the file

kanban:admin is deliberately reserved for high-impact operations: board lifecycle, membership, visibility, and permanent deletion. It is not required for every HTTP DELETE — deleting your own comment, a label, or a subtask is a normal kanban:write capability.

Choosing scopes for an integration

  • A dashboard, reporting job, or read-only bot needs only kanban:read.
  • Most integrations that create and move cards need kanban:write.
  • Reserve kanban:admin for administrative tooling that manages board membership, visibility, or deletion — and issue it as a separate token so the day-to-day integration does not carry destructive capability.

You can always inspect a token's effective scopes at runtime with GET /account:

cURL:

curl -sS "$KANBAN_API_BASE_URL/account" \
-H "Authorization: Bearer $KANBAN_API_TOKEN"

JavaScript:

const baseUrl =
process.env.KANBAN_API_BASE_URL ?? "https://app.filetag.ai/api/kanban/v1";
const token = process.env.KANBAN_API_TOKEN;

async function main() {
const response = await fetch(`${baseUrl}/account`, {
headers: { Authorization: `Bearer ${token}` },
});
const payload = await response.json();
if (!response.ok) {
throw new Error(
`${payload.error.code}: ${payload.error.message} (request ${payload.error.request_id})`
);
}
console.log("scopes:", payload.data.scopes.join(", "));
}

main().catch((error) => {
console.error(error);
process.exit(1);
});

Python:

import json
import os
import urllib.request

BASE_URL = os.environ.get(
"KANBAN_API_BASE_URL", "https://app.filetag.ai/api/kanban/v1"
)
TOKEN = os.environ["KANBAN_API_TOKEN"]

request = urllib.request.Request(
f"{BASE_URL}/account",
headers={"Authorization": f"Bearer {TOKEN}"},
)
with urllib.request.urlopen(request) as response:
payload = json.load(response)

print("scopes:", ", ".join(payload["data"]["scopes"]))