/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": "bu31scprhhs8ywtrmklo47u8x",
    "name": "string",
    "parentId": "7muxj6lnc7mju4tupsw9daw0f",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "4lyiynyd2gg9lgyszb3opzigo"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "66gt6rr052jib6et0o1xnm0iu",
            "parentId": "evt3ges89e77tnb08jepnuqht"
        }
    ]
}

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": "axnle0au6qc14u5fmkbm9u65l",
    "name": "string",
    "parentId": "9vlh2ycnitkg454hq4angrhd8"
}

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

{
    "id": "bu31scprhhs8ywtrmklo47u8x",
    "name": "string",
    "parentId": "7muxj6lnc7mju4tupsw9daw0f",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "4lyiynyd2gg9lgyszb3opzigo"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "66gt6rr052jib6et0o1xnm0iu",
            "parentId": "evt3ges89e77tnb08jepnuqht"
        }
    ]
}

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": "axnle0au6qc14u5fmkbm9u65l",
    "name": "string",
    "parentId": "9vlh2ycnitkg454hq4angrhd8"
}

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

{
    "id": "bu31scprhhs8ywtrmklo47u8x",
    "name": "string",
    "parentId": "7muxj6lnc7mju4tupsw9daw0f",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "4lyiynyd2gg9lgyszb3opzigo"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "66gt6rr052jib6et0o1xnm0iu",
            "parentId": "evt3ges89e77tnb08jepnuqht"
        }
    ]
}

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.