Skip to main content
Beta. Transcribe a prerecorded audio or video file with a single HTTP request. You receive the complete transcript when processing finishes.
Use POST /v1/asr/transcribe for a recording you already have. For audio you are still capturing, use the streaming WebSocket.

Send a recording

Send multipart/form-data with exactly one input: Use a direct media URL, not a webpage or a storage object identifier. A signed URL must remain valid while Chariot downloads the file. URLs that require additional authentication headers or access to a private network cannot be fetched. Send an encoded media file such as WAV, MP3, FLAC, OGG, M4A, AAC, or WebM. Video containers such as MP4 must contain an audio track. Chariot reads the audio from the file; you do not need to convert it to the raw audio format used by the WebSocket API.

Upload a file

Create an API key in the Dashboard. Keep it on your server and supply it through the CHARIOT_API_KEY environment variable.
Let your HTTP client set Content-Type and the multipart boundary. The file field contains the file bytes, not a local path string or base64 text. The Python example uses the requests package. The JavaScript example runs on a Node.js version with fetch, FormData, and Blob support.

Use a URL

Supply the URL as a form field on the same endpoint:
Set AUDIO_URL to the full media URL, including any signature query parameters. Send the URL instead of input_audio_file.

Choose transcription settings

Add these fields to the same multipart form. Omit them to use the defaults.
See the supported language codes and writing styles. The language setting does not request translation. File settings are form fields, rather than WebSocket query parameters.

Read the result

A successful request returns 200 with JSON. Input audio channels are mixed to mono and returned as one transcript:

Request word timestamps

Add include_timestamps=true to the multipart form:
The complete response includes each timed word as text, start, and end:
Times are estimates in seconds from the start of the file, including leading silence. They are not processing timestamps. The response still arrives once transcription finishes; this option does not stream the response. When requested, words: null means timing data was unavailable or invalid, while words: [] means the upstream returned no timed words. You still receive the transcript if timing data is unavailable. When the option is omitted or false, words remains an empty array. Confidence scores and speaker labels are not returned.

Request lifecycle

Keep the HTTP request open until the response arrives. Configure your client and any proxy timeouts to allow for both upload and transcription. This is synchronous file transcription, sometimes called batch or offline transcription. It does not return a background job to poll, deliver webhook results, or accept a CSV or multiple files in one request. Use a separate request for each recording and bound how many requests you send concurrently. For durable background work, multiple recordings, polling, and completion webhooks, use Async transcription (Beta).
A disconnected or timed-out request does not guarantee that processing finished or that you can resume it. Retrying submits a new transcription request and can result in another charge if the earlier request completed.
Usage is based on audio duration. File transcription shares ASR concurrency with streaming. See Credits & pricing and Rate limits & concurrency.

Handle errors

File acceptance constraints can change during beta. Handle validation errors instead of assuming that every recording can be accepted. Application errors use the statusCode, error, and message fields described in Errors & troubleshooting. An upload rejected with 413 before processing can instead return a detail message. Check the HTTP status before reading the body.