Sources and watching
Where a transcription job reads audio from — buckets, file servers, Drive, uploads, URLs or your own API — and how a job keeps running once the first batch is done.
A job reads from exactly one source, chosen when it is created. Three of them can be watched, which turns a one-off batch into a job that keeps transcribing whatever arrives.
Upload and ZIP
Files picked from your machine, or a single ZIP archive. A ZIP's folder structure is kept and can enrich the recordings inside it the same way a dated export tree does.
Uploaded audio is staged on our side long enough to transcribe it and then deleted, unless Keep source audio is on.
S3 bucket
Any storage that speaks the S3 protocol: Amazon S3, Cloudflare R2, MinIO or another self-hosted server, Wasabi, Backblaze B2, DigitalOcean Spaces, and Google Cloud Storage through its interoperability keys. The connection — endpoint, region, access key — is saved once and reused by any number of jobs, so a rotated key is changed in one place.
Then pick the bucket and, optionally, a prefix to read only part of it.
This is the cheapest source available. Each recording is handed to the transcription provider as a short-lived signed link to your bucket, so the audio travels straight from your storage to the provider and never passes through us — no copy, no proxy, nothing to clean up afterwards. Your keys stay on our side and are never shared.
Tip
Read-only keys are enough. A transcription job never writes to your bucket, and never deletes anything unless you explicitly choose Delete it under After transcribing.
FTP / SFTP
A folder on your own server, over SFTP, FTPS or plain FTP. As with buckets, the connection is a saved credential: host, port, username, and either a password or a private key.
- Host key fingerprint (SFTP) — left blank, any host key is accepted: the connection is encrypted, but to whoever answers on that address. Fill it in and anything else is refused.
- Passive mode — on unless your server says otherwise.
- Include sub-folders — a dated export tree enriches rows the same way a ZIP's folders do.
Recordings are never copied here. Each one is read from your server at the moment it is transcribed, so a cancelled job leaves nothing behind.
Warning
Plain FTP sends the password and the recordings in the clear. Use it only across a private link or VPN — if the server offers SFTP or FTPS, prefer those.
Google Drive
A Drive folder, read two ways:
| Access | When to use it |
|---|---|
| Shared link | The folder is already shared with anyone who has the link. We read it with a key that can only ever reach files shared that way — no consent screen, and no access to the rest of your Drive |
| Connected account | For folders you would rather not share publicly. Read-only access, connected from inside the job form |
Either way the files stay in your Drive: each one is streamed to the transcription provider when it is needed, and no copy is kept. Check access counts the audio files it can see before you start, so a mis-shared folder is caught in the form rather than in an empty job.
URLs
One audio URL per line — public, or pre-signed. Like a bucket, the link is passed to the provider as given.
API
A job that stays open. It is configured once in the dashboard — language, speakers, analysis outputs, concurrency — and another system hands it recordings one at a time. See Pushing recordings over the API.
Watching a folder
S3, FTP/SFTP and Drive jobs can keep watching. Each check asks only for what has arrived since the last one, so the cost follows the arrivals rather than the size of the folder.
A watch is not a job that takes longer; it is a job that never ends, and those fail differently. Four settings exist for exactly those failures:
| Setting | The failure it prevents |
|---|---|
| Ignore files newer than | A recording still being uploaded is transcribed half-finished. A file is left alone until it has been sitting still for the chosen window (30 seconds to 15 minutes) |
| Warn me if nothing arrives for | The one failure a watch cannot report for itself. If the system at the other end stops sending, every check still succeeds and finds nothing — which looks exactly like a quiet day. Say roughly how often you expect recordings and the job says so when they stop |
| Pause importing above | A watch pointed at a large archive keeps queueing, and billing, faster than it can transcribe. Importing stops while this many recordings are queued and resumes as they clear |
| After transcribing | What decides whether this still works in a year. Finding new recordings means listing the folder, so a folder that only ever grows is re-listed in full on every check and gets slower every day |
After transcribing offers Leave it in place, Move it aside (to a path you name) or Delete it, and is available for file servers and buckets. Nothing is ever touched until it has been transcribed successfully.
Drive is deliberately left out of that last one: a customer's Drive folder is a place people work in, not a queue, and a transcription job should not be moving their files around.
Warning
Delete it removes the original recording from your own server or bucket once we have transcribed it. We keep the transcript, not the audio. If you might need the recording afterwards, move it aside instead.
Changing a running job
Open a job's Details action to change the configuration — including the enrichment mapping and agent or contact linking — and it is applied to every recording the job already holds. See Details and linking.