Transcription API hosted in Europe: where your media is processed
Audio carries personal data, so picking a transcription API is not only about model accuracy. Where media is processed, how long files live and how deletion propagates matter just as much — here is Techtuel’s answer, and the questions to ask any provider.
Audio and video can contain personal data, confidential discussions, customer information or unpublished material.
For European applications, choosing a transcription API is therefore not only a question of model accuracy.
You may also need to know:
- where media is downloaded;
- where audio is processed;
- which cloud providers are involved;
- how long temporary files remain available;
- where transcripts are stored;
- how content can be deleted;
- whether additional subprocessors receive the data.
Techtuel is a web media transcription API built and hosted in France.
It converts YouTube videos, podcasts, RSS sources, audio files and video URLs into structured transcripts while keeping the processing chain on European infrastructure.
Built and hosted in France
Techtuel's infrastructure is operated using French providers:
- media processing on OVHcloud in Gravelines;
- secrets hosted with Scaleway;
- no AWS, Google Cloud or Microsoft Azure dependency in the transcription chain.
The infrastructure page sets out these technical choices in full.
The objective is straightforward: keep submitted media and generated transcripts within a French and European technical environment.
Your application
↓
Techtuel API
↓
European media processing
↓
Timestamped transcriptSubmit a URL instead of moving files between clouds
Many transcription workflows create several copies of the same content:
- download the media to your application;
- store it temporarily;
- upload it to a speech-to-text provider;
- download the result;
- delete the temporary copies.
Techtuel accepts the original source URL directly.
curl https://api.techtuel.com/v1/transcribe \
-H "Authorization: Bearer $TECHTUEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"source_url": "https://cdn.example.eu/private/interview.mp4"
}'The service resolves the source, processes the media and returns the transcript in the same response.
This reduces the number of infrastructure components your own application needs to operate.
Asynchronous jobs for long recordings
A one-hour interview cannot be tied to the lifetime of a single HTTP request. POST /v1/transcribe therefore waits up to thirty seconds — tunable with ?wait=, up to 120 — and if the media is still being processed it answers 202 with the transcription id instead of the text:
{
"id": "job_9f2c",
"status": "processing"
}That is not an error. The job keeps running, and you retrieve it later:
GET /v1/transcriptions/job_9f2cThe states are:
processing → completed
↘ failedOnly completed and failed are terminal. A job is also briefly claimed while a worker takes it; handle it like processing. A failed job carries an error message and can be resubmitted with POST /v1/transcriptions/{id}/retry. The asynchronous transcription API page documents the full lifecycle, including POST /v1/transcriptions, which returns the job id immediately without waiting.
There is no webhook callback — you poll the job. That means one fewer publicly reachable endpoint to authenticate and secure on your side, which is a meaningful simplification when the content is confidential.
This pattern is the right tool when you:
- process long recordings;
- use background workers;
- control concurrency;
- retry transient failures;
- ingest media catalogues;
- separate transcription from indexing.
Data minimization by architecture
You can reduce risk by sending and storing only what your product needs.
Useful techniques include:
- transcribe only the required media;
- avoid storing the original file in your own infrastructure;
- keep the raw transcript only when necessary;
- remove unnecessary metadata;
- redact sensitive fields;
- apply tenant-level access controls;
- encrypt stored transcripts;
- set an automatic retention period;
- delete embeddings when the source transcript is deleted.
Remember that embeddings and summaries may still be derived personal data when their source contains personal information.
Build a deletion workflow
A production deletion command can coordinate every copy:
type DeleteMediaCommand = {
tenantId: string
mediaId: string
}
export async function deleteMedia(command: DeleteMediaCommand): Promise<void> {
// DELETE /v1/transcriptions/{id} on the Techtuel side...
await deleteRemoteTranscription(command.mediaId)
// ...then every copy you derived from it.
await deleteTranscriptChunks(command.tenantId, command.mediaId)
await deleteSearchDocuments(command.tenantId, command.mediaId)
await deleteLocalTranscript(command.tenantId, command.mediaId)
await recordDeletion(command)
}The exact implementation depends on your storage, but the principle is important: deletion must propagate to every derived asset.
Supported media workflows
One endpoint can process multiple source types:
- YouTube videos;
- podcast episodes;
- podcast and RSS-oriented sources;
- direct MP3, WAV, M4A and other common audio URLs;
- MP4 and common video URLs;
- uploaded private files (
POST /v1/uploads, thenupload_id); - media available from supported webpages.
The output can be retrieved as:
- plain text (
?format=txt); - JSON with timestamped segments (
?format=json); - SRT subtitles (
?format=srt); - VTT subtitles (
?format=vtt).
Example JSON:
{
"id": "job_9f2c",
"status": "completed",
"title": "Customer research interview",
"language": "en",
"minutes": 31.0,
"transcript": "Thank you for joining this interview...",
"segments": [
{
"start_seconds": 0.0,
"text": "Thank you for joining this interview."
}
]
}The transcript sits in transcript, and a segment holds exactly two fields: start_seconds and text. There is no end time — a segment runs until the next one begins. The transcription API with timestamps page describes that shape in detail.
File processing and deletion
Uploaded files are processed and then deleted.
The generated transcript remains accessible through the API and can be deleted by the customer with DELETE /v1/transcriptions/{id}.
A robust application should still implement its own lifecycle:
- delete the transcript in Techtuel;
- delete local transcript copies;
- delete chunks and embeddings;
- invalidate search indexes;
- record the deletion event;
- apply the same policy to backups.
Deletion is only complete when every derived copy in your own system has also been removed.
European hosting is not the same as automatic GDPR compliance
Using European infrastructure can simplify data mapping and vendor review, but it does not make every processing operation compliant by itself.
Your organization remains responsible for determining:
- the lawful basis for transcription;
- whether participants must be informed;
- whether consent is required;
- how long media and transcripts are retained;
- who can access them;
- whether sensitive data is involved;
- how data-subject requests are handled;
- whether international transfers exist elsewhere in your stack.
Techtuel should be evaluated as one processor within your complete application architecture.
For legal conclusions, consult your data protection officer or qualified legal counsel.
Designed for European developer teams
Techtuel is intended for developers building:
- media monitoring products;
- podcast platforms;
- journalistic research tools;
- internal knowledge bases;
- searchable video libraries;
- accessibility workflows;
- RAG systems;
- content production tools;
- archives and documentation platforms.
The API hides the source-specific media pipeline while returning a predictable structure that can be connected to your own database or AI workflow.
Use private media URLs carefully
A private or signed media URL should:
- use HTTPS;
- expire after a short period;
- expose only the intended object;
- avoid permanent credentials in query parameters;
- be generated server-side;
- be logged without leaking its full secret value.
Example server-side flow:
User requests transcription
↓
Your backend authorizes access
↓
Your storage creates a short-lived signed URL
↓
Your backend sends the URL to Techtuel
↓
Techtuel processes and deletes the mediaNever expose your Techtuel API key in frontend code. Keys are bearer credentials: Authorization: Bearer txl_... belongs on your server only.
Techtuel compared with a self-hosted transcription stack
Self-hosting may provide maximum infrastructure control, but it introduces operational responsibilities.
| Area | Techtuel | Self-hosted stack |
|---|---|---|
| Media source extraction | Included | You operate it |
| Model serving | Managed | You operate it |
| GPU capacity | Managed | You provision it |
| Scaling | Managed by the service | You design it |
| Monitoring | Shared responsibility | You own it |
| Model upgrades | Managed | You plan them |
| Data location | France / Europe | Your chosen infrastructure |
| Custom model control | Limited to service features | Full control |
| Maintenance effort | Lower | Higher |
Self-hosting can be the right choice for strict isolation, custom models or very large predictable workloads.
A managed European API can be preferable when the goal is to ship a product without operating the complete media and inference platform.
Questions to ask any transcription API provider
Before sending production content to a service, document the answers to these questions.
Infrastructure
- In which country is the media processed?
- Where are the transcripts stored?
- Which cloud providers are used?
- Are American hyperscalers involved?
- Are inference providers or other subprocessors involved?
Retention
- Are original files stored?
- For how long?
- Are temporary files deleted automatically?
- Can customers delete transcripts?
- How are backups handled?
Security
- Is data encrypted in transit?
- How are API keys stored?
- Is tenant data isolated?
- Are access events logged?
- Are private URLs or signed URLs supported safely?
Legal and contractual terms
- Is a data processing agreement available?
- Is a subprocessor list available?
- Are processing locations documented?
- Are security incidents covered contractually?
- Does the provider reuse customer data for training?
These questions matter regardless of whether the provider is European or American.
Frequently asked questions
Where is Techtuel hosted?
Media processing runs on OVHcloud in Gravelines, France, with secrets hosted by Scaleway.
Does Techtuel use AWS, Azure or Google Cloud?
No. The transcription chain does not depend on AWS, Microsoft Azure or Google Cloud.
Are uploaded files retained?
Uploaded files are processed and then deleted. The generated transcript remains available through the API until you delete it.
Does European hosting guarantee GDPR compliance?
No. Infrastructure location is one element of compliance. Your use case, lawful basis, retention, security controls, contracts and the rest of your processor chain must also be assessed.
Can I send a signed URL?
Yes, as a source_url or audio_url. Use short-lived, least-privilege signed URLs and confirm current limits in the API documentation.
Does the API return timestamps?
Yes, start times. Each JSON segment has start_seconds and text, with no end field; SRT and VTT output is available via ?format=.
Can I use Techtuel for RAG?
Yes. Store the transcript segments with their source URL and start times, create chunks and embeddings, then index them in your retrieval system.
Keep your transcription pipeline in Europe
Use one API to transform audio, video, YouTube and podcast sources into structured text on infrastructure built and hosted in France.