> ## Documentation Index > Fetch the complete documentation index at: https://docs.tiro.ooo/llms.txt > Use this file to discover all available pages before exploring further. # Reorder Folders > Set the display order of sibling folders. Provide every sibling's ID in the desired order; positions are assigned by array index. The workspace is inferred from the first folder ID. Requires edit access. ## OpenAPI ````yaml /openapi.yaml post /v1/external/folders/reorder openapi: 3.1.0 info: title: Tiro API description: AI-powered note-taking and voice file processing API version: 1.0.0 contact: name: Tiro Support email: support@tiro.ooo url: https://tiro.ooo servers: - url: https://api.tiro.ooo description: Production server security: - BearerAuth: [] tags: - name: Note description: Operations for managing notes and their paragraphs - name: Note Share Link description: Manage share links for notes - name: Note Summary description: Operations for retrieving note summaries - name: Note Document description: Template-based document generation from notes - name: Note Document Template description: Operations for managing note document templates - name: Folder description: Operations for retrieving folders - name: Voice File description: Operations for voice file processing - name: Word Memory description: > Manage word memories to improve voice transcription accuracy. Register important terms like company names, people's names, and product names so Tiro recognizes them precisely during recording. Personal word memories (User) and a workspace's shared word memories (Workspace) are managed separately. The legacy team word memory endpoints (`/v1/external/teams/me/word-memories`) are deprecated — removed on 2026-06-30 — in favor of the workspace-explicit `/v1/external/workspaces/{workspaceGuid}/word-memories`. - name: Wiki description: | Access workspace wikis — unified knowledge graphs built from notes. Requires a workspace with wiki plan and activation enabled. - name: Organization description: > Endpoints for organization API keys. An organization key is issued by an organization admin, carries fixed scopes chosen at issuance, and can reach the notes in every workspace that belongs to the organization. Built for server-to-server integrations such as CRM sync — receive `note.ended` webhook events, generate documents for notes, and reconcile with the organization notes list. - name: Organization Management description: Operations for the authenticated user's organization. paths: /v1/external/folders/reorder: post: tags: - Folder summary: Reorder Folders description: > Set the display order of sibling folders. Provide every sibling's ID in the desired order; positions are assigned by array index. The workspace is inferred from the first folder ID. Requires edit access. operationId: reorderFolders requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/ReorderFoldersRequest' example: orderedFolderIds: - '12346' - '12345' - '12347' responses: '204': description: Display order updated '400': description: >- Bad request — empty list, duplicate IDs, folders not found, or folders span more than one workspace content: application/json: schema: $ref: '#/components/schemas/Error' '401': description: Unauthorized — missing API key, or a team-only key was used content: application/json: schema: $ref: '#/components/schemas/Error' '403': description: Forbidden — no edit access content: application/json: schema: $ref: '#/components/schemas/Error' '404': description: The first folder in the list was not found content: application/json: schema: $ref: '#/components/schemas/Error' components: schemas: ReorderFoldersRequest: type: object description: Set the display order of sibling folders. required: - orderedFolderIds properties: orderedFolderIds: type: array minItems: 1 description: > Folder IDs in their new display order; positions are assigned by array index. All folders must belong to the same workspace, which is inferred from the first ID. items: type: string example: - '12346' - '12345' - '12347' Error: type: object required: - error properties: error: type: object required: - code - errorType - message properties: code: type: integer description: > 6-digit error code in `AAABBB` form: first 3 digits match the HTTP status, last 3 digits are a per-status serial (e.g. `404018`). Use only when you need to distinguish specific error cases within the same HTTP status — values may be added or renumbered across releases. For general client branching, prefer `errorType`. example: 404018 errorType: type: string description: > Stable, coarse-grained error category. Recommended default for client-side branching: the value-to-status mapping is part of the API contract and will not change without a breaking-change notice. Typical use: - `unauthorized` → trigger re-authentication - `forbidden` → surface a permission error to the user - `not_found` → treat as missing resource - `too_many_requests` → back off and retry - `internal_error` → retry with exponential backoff enum: - bad_request - unauthorized - forbidden - not_found - not_acceptable - conflict - payload_too_large - unprocessable_entity - too_many_requests - internal_error example: not_found message: type: string description: >- Human-readable error message. Not stable; do not use for branching. example: 'No team found for user #217' detail: type: string nullable: true description: Additional error details example: null securitySchemes: BearerAuth: type: http scheme: bearer description: API key in format {id}.{secret} ````