Permanently delete an attachment, its stored file, and supported image variants.
The method verifies the attachment owner or the current comment-editing context, attempts to remove the file from permanent storage, deletes the attachment record, recalculates related attachment counters, and publishes a WebSocket update.
This is a hard-delete operation. The attachment record is not assigned a removed status and cannot be restored through this API.
The number in the URL path (/1/) is the organization identifier — referred to as account_id.
This value must match the account associated with the provided session_id, token, or project_token.
This endpoint accepts both:
Because this method permanently deletes data, POST is recommended.
POST https://api.doboard.com/42/attachment_delete
Content-Type: application/x-www-form-urlencoded
attachment_id=301&session_id=abc123xyz
In this example:
42 is the organization/account ID.attachment_id=301 identifies the attachment to delete.session_id=abc123xyz is used for authentication.
attachment_idis required.
Required
Provide one of:
session_id – for an authenticated usertoken – for public task guest accessproject_token – for public project guest accessDeleting an attachment also requires ownership or an allowed comment-editing context.
If the account ID in the URL does not match the account tied to the session or token, the request will be rejected.
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
session_id |
string | Yes* | – | Authenticated user session ID. |
token |
string | Yes* | – | Public task guest-access token. |
project_token |
string | Yes* | – | Public project guest-access token. |
attachment_id |
int | Yes | – | ID of the attachment to delete. |
* One of session_id, token, or project_token is required.
Ownership refers to the user who uploaded the attachment.
It does not refer to the user who owns the related comment.
The attachment owner can delete the attachment unless another user has an active editing session for the relevant task comment.
The editing session remains active for 15 minutes from its last recorded editing time.
A user who did not upload the attachment can delete it only when all of the following conditions are met:
A guest can delete an attachment owned by that guest, subject to the editing-lock rule.
A guest cannot delete an attachment uploaded by another user.
A non-owner cannot delete an attachment from a track-only comment because the editing exception applies only to the first active comment of a task.
The attachment owner can delete an attachment from a track-only comment because no task-comment editing lock is resolved for that attachment.
No separate administrator bypass is applied.
An administrator who does not own the attachment must satisfy the same first-comment and editing-state requirements as another authenticated non-owner.
For task attachments, editing state is resolved from the first active comment of the related task.
| User context | Deletion permission |
|---|---|
| Attachment owner; no other active editor | Allowed |
| Attachment owner; another user has an active editing session | Denied |
| Guest who does not own the attachment | Denied |
| Non-owner; attachment is not on the first active task comment | Denied |
| Non-owner; first active comment with a current editing session | Allowed |
| Non-owner; first active comment edited by the same user within the last 60 seconds | Allowed |
| Non-owner; editing session expired and no recent edit is recorded | Denied |
If an attachment belongs to a later task comment, the attachment owner can still be affected by an active editing lock recorded on the task’s first active comment.
No additional project-membership check is performed after authentication. Deletion permission is based on attachment ownership and comment-editing state.
Before deleting the database record, the method attempts to delete the file identified by the attachment’s stored URL.
For URLs ending with one of these extensions:
pngjpgwebpThe method also attempts to delete two derived inline image variants:
{filename}-desktop-inline.{extension}
{filename}-mobile-inline.{extension}
For example, deleting:
image.webp
also attempts to delete:
image-desktop-inline.webp
image-mobile-inline.webp
Image-variant detection is based on the extension at the end of the stored URL.
The following extensions do not trigger this additional inline-variant deletion:
jpegpng, jpg, or webpThe method does not load or explicitly delete the file referenced by the attachment’s URL_thumbnail field.
The attachment record is permanently removed from the attachments table.
The following attachment data is loaded before deletion and can be used by logging and the WebSocket event:
| Field | Type | Description |
|---|---|---|
attachment_id |
int | Identifier of the deleted attachment. |
user_id |
int/null | ID of the user who uploaded the attachment. |
URL |
string | Stored file URL used for the storage-deletion attempt. |
filename |
string | Attachment filename used in the activity log. |
comment_id |
int | ID of the related comment. |
task_id |
int/null | ID of the related task. |
track_id |
int/null | ID of the related track. |
The database record is removed with a hard delete. Fields such as status, removed, or deleted_at are not set.
{
"data": {
"operation_status": "SUCCESS",
"attachment_id": 301
}
}
attachment_id contains the ID of the deleted attachment.
The response does not return the complete deleted object or the result of the file-storage deletion attempt.
{
"data": {
"operation_status": "FAILED",
"operation_message": "attachment_id is required"
},
"error_message": "attachment_id is required",
"error_no": 1101
}
Validation, access, and database errors defined by the method are returned with HTTP status 200.
Authentication failures use HTTP status 401.
After successful deletion of the attachment record, the method:
task_id is present.track_id is present.DELETE event to the account WebSocket channel when realtime publishing is available.Example WebSocket event:
{
"action": "DELETE",
"object": "attachments",
"data": {
"attachment_id": 301,
"user_id": 5,
"URL": "https://example.com/path/screenshot.png",
"filename": "screenshot.png",
"comment_id": 501,
"task_id": 101,
"track_id": 12
}
}
The storage-deletion attempt occurs before the attachment record is deleted.
The success response is based on successful deletion of the database record. A separate file-storage deletion result is not included in the response.
This means:
| HTTP Code | error_no |
Message | Description |
|---|---|---|---|
401 |
– | Unauthorized |
Missing or invalid session_id, token, or project_token. |
200 |
7 |
limit reached |
Too many failed session-validation attempts from the same IP address. |
200 |
1101 |
attachment_id is required |
attachment_id was not provided or was empty. |
200 |
1102 |
Attachment Not Found |
The specified attachment does not exist. |
200 |
1103 |
Access denied |
The current user does not satisfy the attachment ownership or comment-editing requirements. |
200 |
0 |
Internal API Error |
The attachment record could not be deleted. |
attachment_id is required.png, jpg, or webp.URL_thumbnail is not explicitly processed by this method.attachment_id.