Job-based workflow

• Poll the status endpoint at reasonable intervals (e.g. every 10–30 seconds) until completed or failed
• Download transcript JSON from transcript_urls soon after completion; signed URLs expire (e.g. 24 hours)
• Implement proper error handling and retry logic for failed jobs or network errors
• Respect rate limits (100 jobs/hour, 10 concurrent jobs per API key) and use exponential backoff if needed

Audio quality

• Use high-quality audio files for better transcription accuracy
• Ensure audio is in a supported format (.aac, .flac, .m4a, .mp3, .mp4, .mkv, .wav, .webm, .3gpp)
• Minimize background noise when possible
• For best results, use audio with clear speech; max 1GB per file

Security

• Never expose API keys in client-side code
• Store keys securely using environment variables
• Rotate API keys regularly
• Use different keys for development and production
• Monitor API key usage for suspicious activity

Performance

• Submit multiple files in one job (up to 100 audio_urls) for batch processing
• Use the results array in the status response for per-file progress and metadata
• Optimize audio file sizes and use public or pre-signed URLs that are reliably accessible

Error handling

See the Errors guide for the full list of status codes, envelope shapes, per-unit error codes, and a reference retry/backoff implementation. Two habits that belong here rather than in the reference: always poll to a terminal job status (COMPLETED / PARTIAL / FAILED — the same vocabulary for both transcription and translation) before deciding an operation succeeded, and log failed job_ids so you can re-submit without losing context.

For more information, check out our other guides and the API Reference.