File the bug into the ClickUp list it belongs in
Connect one personal API token, choose a space and a list — folders included — and a tester files the task straight from a failed test, with the description written and the screenshot attached.
Personal API token · no ClickUp app to install
Checkout — assertion failed on the payment step
Open task →
- One personal token
- no ClickUp app, no admin approval
- Spaces, then lists
- folders walked and merged
- A task in your list
- a name, a description, the screenshot
- One-way filing
- nothing polls ClickUp back
What gets filed, and how
Every filing creates one ordinary task in the list you chose, carrying exactly three things and a link back.
A task in the list you nominate
A ClickUp task lives in a list, so filing POSTs a task to the exact list you chose. Every filing lands there — there is no routing by product, platform or severity.
The failure carried into the description
The task arrives with a name pre-filled from what you were testing and a description taken from the body you wrote — steps, expected result, actual result and a link back to the run.
The screenshot attached, then dropped
The image is uploaded to the new task under ClickUp's own attachment field name, and then discarded on our side — it is never written to our object storage. If it is over the attachment ceiling or ClickUp refuses it, the task is still created and you are told the screenshot did not attach.
The list's default status, and nothing else
Created with a list, a name and a description, the task takes the list's default status. No assignee, priority, due date, tags, custom fields or custom task type are set — a ClickUp Automation on the receiving list can apply those on arrival.
Set up once for the organisation
One personal API token, pasted into Organization then Integrations then Project management. ClickUp takes the project-management slot and can sit alongside a separate defect tracker, with the filing dialog asking which one to use.
Connect, don't migrate
Filing is one-way and nothing polls ClickUp. The state of the work lives in ClickUp; what we keep is the link between the session or scan and the task it produced, including the task URL.
What the task gets, and what it leaves alone
createIssue sends a list, a name and a description. Everything below that line is a field we do not touch.
Set on the task
- The list — the destination you chose
- Name — editable before you send
- Description — steps, expected, actual, link back
- Attachment — the screenshot, then discarded
Left to ClickUp
- Status — the list's default
- Assignee, priority, due date, tags
- Custom fields and custom task type
- Sprints and dependencies — none set
Not part of this
- Docs, Goals and Whiteboards — untouched.
- No status read-back — closing the task in ClickUp changes nothing here.
- One list for the whole organisation; archived spaces are hidden.
Frequently asked questions
Yes. A tester files a task straight from a device session, a failed automated test or an accessibility scan into the ClickUp list you chose — the name pre-filled, the description written and the screenshot attached. Filing is one-way, and every filing lands in that one list.
One ClickUp personal API token from your own account settings. Paste it into Organization then Integrations then Project management, pick a space, pick a list, and filing is live. There is no ClickUp app to publish and no workspace admin approval to wait for.
Check that you have not pasted 'Bearer ' in front of it. ClickUp is unusual: its personal tokens go into the Authorization header on their own, with no scheme prefix, which is the opposite of what most APIs expect. A token with a prefix attached will be refused even though the token itself is valid. The token is stored encrypted with AES-256-GCM — a fresh random initialisation vector per record and an authentication tag, with the key held in an environment variable rather than the database — and no endpoint ever hands it back.
Because a ClickUp task lives in a list, and lists live in a space — sometimes directly, sometimes inside a folder. The first step shows the spaces your token can see across every team, leaving archived ones out; the second shows every list in that space, including the ones inside folders. A list that lives in a folder is shown as the folder name and the list name together, separated by a slash, so a 'Bugs' list in the Mobile folder and a 'Bugs' list in the Web folder are distinguishable rather than being two identical entries.
No. The task is created with a list, a name and a description, so it takes the list's default status and nothing else is set: no assignee, no priority, no due date, no tags, no custom fields, no custom task type, and no sprint, dependency or relationship. A ClickUp Automation on the receiving list can apply those on arrival, which is where that rule belongs anyway.
Yes. The task is created first and the image attached second, uploaded to the new task and then discarded on our side — it is never written to our object storage. If it is larger than the attachment ceiling, or ClickUp rejects it, the task is still created and the result tells you the screenshot did not attach.
Filing is one-way and nothing polls ClickUp; the state of the work lives there, and what we keep is the link between the session or scan and the task, including its URL. An organisation holds one project-management connection and one defect-tracker connection at the same time, and the filing dialog asks which one to use. Connecting a second project-management tool replaces ClickUp rather than sitting beside it.
Connect ClickUp and file the next one from the session
Paste a token, choose a space and a list, and the reporting control does the rest. Every tool we can file into is listed on the integrations page.