/api/helpdesk/processes/folders/{folderId}

Exposes process folders below /api/helpdesk/processes/folders.

The collection resource returns the protected root node. The root contains compact metadata for its direct processes and one shallow level of FolderSummary children. Clients resolve a child folder to obtain that folder's direct processes and next-level children. This keeps a large folder tree from being repeated in every response; no parentId query parameter is required.

The root has a stable, generated identifier and parentId=null. Every direct child refers to that root identifier in its parentId. Folder names and parent identifiers are the only persisted writable properties; read-only identifiers are accepted and ignored for GET-to-PUT/PATCH round-trips. PATCH updates are staged and persisted by commit; there is no separate move action. A normal DELETE is limited to empty folders. Recursive deletion is an explicit confirmation-protected DELETE action.

Deletes this folder only when it has no direct processes and no direct child folders.

# Request
DELETE /api/helpdesk/processes/folders/<folderId> HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>

# Response
HTTP/1.1 204 No Content

Exposes process folders below /api/helpdesk/processes/folders.

The collection resource returns the protected root node. The root contains compact metadata for its direct processes and one shallow level of FolderSummary children. Clients resolve a child folder to obtain that folder's direct processes and next-level children. This keeps a large folder tree from being repeated in every response; no parentId query parameter is required.

The root has a stable, generated identifier and parentId=null. Every direct child refers to that root identifier in its parentId. Folder names and parent identifiers are the only persisted writable properties; read-only identifiers are accepted and ignored for GET-to-PUT/PATCH round-trips. PATCH updates are staged and persisted by commit; there is no separate move action. A normal DELETE is limited to empty folders. Recursive deletion is an explicit confirmation-protected DELETE action.

# Request
GET /api/helpdesk/processes/folders/<folderId> HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>

# Response
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": "62qi6ajo52yn9abouufaei55j",
    "name": "string",
    "parentId": "dpevlzkn8tmr17j3sswuelko0",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "f4qoq1fl9kggbn0fzuargdh1i"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "a9vyyb31g7c9y4utamn9w2e21",
            "parentId": "4ff336qhr20u1e48yutd30qs8"
        }
    ]
}

Exposes process folders below /api/helpdesk/processes/folders.

The collection resource returns the protected root node. The root contains compact metadata for its direct processes and one shallow level of FolderSummary children. Clients resolve a child folder to obtain that folder's direct processes and next-level children. This keeps a large folder tree from being repeated in every response; no parentId query parameter is required.

The root has a stable, generated identifier and parentId=null. Every direct child refers to that root identifier in its parentId. Folder names and parent identifiers are the only persisted writable properties; read-only identifiers are accepted and ignored for GET-to-PUT/PATCH round-trips. PATCH updates are staged and persisted by commit; there is no separate move action. A normal DELETE is limited to empty folders. Recursive deletion is an explicit confirmation-protected DELETE action.

# Request
PATCH /api/helpdesk/processes/folders/<folderId> HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json

{
    "id": "3885ltockjk37k3qcppky6c47",
    "name": "string",
    "parentId": "02uh7zimihj1zpgazqfmu48fu"
}

# Response
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": "62qi6ajo52yn9abouufaei55j",
    "name": "string",
    "parentId": "dpevlzkn8tmr17j3sswuelko0",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "f4qoq1fl9kggbn0fzuargdh1i"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "a9vyyb31g7c9y4utamn9w2e21",
            "parentId": "4ff336qhr20u1e48yutd30qs8"
        }
    ]
}

Exposes process folders below /api/helpdesk/processes/folders.

The collection resource returns the protected root node. The root contains compact metadata for its direct processes and one shallow level of FolderSummary children. Clients resolve a child folder to obtain that folder's direct processes and next-level children. This keeps a large folder tree from being repeated in every response; no parentId query parameter is required.

The root has a stable, generated identifier and parentId=null. Every direct child refers to that root identifier in its parentId. Folder names and parent identifiers are the only persisted writable properties; read-only identifiers are accepted and ignored for GET-to-PUT/PATCH round-trips. PATCH updates are staged and persisted by commit; there is no separate move action. A normal DELETE is limited to empty folders. Recursive deletion is an explicit confirmation-protected DELETE action.

# Request
PUT /api/helpdesk/processes/folders/<folderId> HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json

{
    "id": "3885ltockjk37k3qcppky6c47",
    "name": "string",
    "parentId": "02uh7zimihj1zpgazqfmu48fu"
}

# Response
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": "62qi6ajo52yn9abouufaei55j",
    "name": "string",
    "parentId": "dpevlzkn8tmr17j3sswuelko0",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "f4qoq1fl9kggbn0fzuargdh1i"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "a9vyyb31g7c9y4utamn9w2e21",
            "parentId": "4ff336qhr20u1e48yutd30qs8"
        }
    ]
}

The status codes 400, 403, 404, 405, 406, 409, 413, 415, and 500 use the same ApiError JSON error format:

{
    "status": 404,
    "code": "route_not_found",
    "message": "The requested API route does not exist.",
    "details": []
}

Request and response schemas used on this page.