> ## 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. # Get Voice File Job > Retrieve the current status and details of a Voice File Job. - Poll this endpoint until status reaches `COMPLETED` or `FAILED` - Once completed, use the transcript and translation endpoints to retrieve results Documentation: [Polling strategy and status meanings](/voice-file/overview#polling-strategy-recommended) ## OpenAPI ````yaml /openapi.yaml get /v1/external/voice-file/jobs/{jobId} 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. Each term has an `entry` and an optional `subEntry` (an alternate spelling or notation). Personal (User), workspace-shared (Workspace), and organization-shared (Organization) word memories are managed separately, and each scope supports bulk create/update/delete (up to 1000 items per request). - 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/voice-file/jobs/{jobId}: get: tags: - Voice File summary: Get Voice File Job description: > Retrieve the current status and details of a Voice File Job. - Poll this endpoint until status reaches `COMPLETED` or `FAILED` - Once completed, use the transcript and translation endpoints to retrieve results Documentation: [Polling strategy and status meanings](/voice-file/overview#polling-strategy-recommended) operationId: getVoiceFileJob parameters: - name: jobId in: path description: The job ID returned from Create Voice File Job required: true schema: type: string responses: '200': description: Job details content: application/json: schema: $ref: '#/components/schemas/VoiceFileJob' '401': description: Unauthorized content: application/json: schema: $ref: '#/components/schemas/Error' '404': description: Job not found content: application/json: schema: $ref: '#/components/schemas/Error' components: schemas: VoiceFileJob: type: object description: > Represents a voice file processing job. Voice File Jobs handle the complete pipeline of audio transcription and optional translation. **Processing Pipeline:** 1. Job created (`CREATED`) → Upload URI provided 2. File uploaded (`UPLOADED`) → Ready for processing 3. Processing started (`PROCESSING`) → STT and translation in progress 4. Processing complete (`COMPLETED`) → Results available **Processing Time Estimates:** | File Duration | Typical Time | |---------------|--------------| | < 5 minutes | 45-75 seconds | | 5-20 minutes | 1-3 minutes | | 20-60 minutes | 3-6 minutes | | 1-4 hours | 6-18 minutes | required: - id - status properties: id: type: string description: Unique job identifier (UUID format) example: b2d1ab32-3fe2-4201-b0b4-391abdbaa023 status: type: string enum: - CREATED - UPLOADED - PROCESSING - COMPLETED - FAILED description: | Current job processing status: - `CREATED`: Job created, waiting for file upload - `UPLOADED`: File uploaded, waiting for processing to start - `PROCESSING`: Transcription/translation in progress - `COMPLETED`: All processing finished, results available - `FAILED`: Processing failed (check errorMessage) example: PROCESSING fileUploadedAt: type: string format: date-time nullable: true description: Timestamp when file upload was completed. Null if not yet uploaded. example: '2025-07-20T10:00:20Z' processStartedAt: type: string format: date-time nullable: true description: Timestamp when processing started. Null if not yet started. example: '2025-07-20T10:01:00Z' processCompletedAt: type: string format: date-time nullable: true description: Timestamp when processing completed. Null if still processing. example: null errorMessage: type: string nullable: true description: Error message if job failed. Null for successful jobs. example: null 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}`. The notes an endpoint returns depend on the key type. A **user key** reaches the notes that user can see in the app, including notes in their own private folders. A **system key** (workspace or organization, no user identity) reaches only notes that sit in a folder shared with all workspace members. Notes in a private folder, in a folder shared with only some members, or in no folder at all fall outside a system key's read scope, and scopes do not widen that boundary. List and search endpoints drop out-of-scope notes from the response without an error. Single-note reads and their sub-resources return `404`, the same response as a deleted note. See [What notes a system key reads](https://docs.tiro.ooo/en/developers/fundamentals/system-key-note-scope). ````