Transcrire un flux RSS de podcast, automatiquement
Lisez le flux, postez l’enclosure de chaque nouvel épisode, gardez votre propre identifiant, interrogez le job jusqu’à completed, stockez le transcript. Une centaine de lignes.
# Cron / GitHub Actions, toutes les 5 minutes
# 1. Nouvel épisode repéré dans le flux → créer le job
JOB=$(curl -s -X POST https://api.techtuel.com/v1/transcriptions \
-H "Authorization: Bearer $TECHTUEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "audio_url": "https://media.example.com/ep-143.mp3" }' \
| jq -r .id)
# 2. Stocker $JOB à côté du guid de l'item RSS, puis sortir.
# 3. Passage suivant : relire les jobs en attente
curl -s https://api.techtuel.com/v1/transcriptions/$JOB \
-H "Authorization: Bearer $TECHTUEL_API_KEY" | jq '.status, .transcript'
# 4. En cas d'échec, relancer sans recréer de job
curl -X POST https://api.techtuel.com/v1/transcriptions/$JOB/retry \
-H "Authorization: Bearer $TECHTUEL_API_KEY"{
"id": "job_5ab7",
"status": "completed",
"title": "Le Podcast — #143",
"language": "fr",
"minutes": 48.9,
"created_at": "2026-07-21T09:30:00Z",
"transcript": "Épisode 143, on démarre…",
"segments": [
{ "start_seconds": 0, "text": "Épisode 143, on démarre" }
],
"error": ""
}Un flux RSS de podcast est un excellent déclencheur : il est public, ordonné, et chaque item porte déjà l’URL du fichier audio dans son enclosure. Le pipeline complet tient en cinq étapes, et aucune n’est compliquée — à condition de ne pas confondre « asynchrone » avec « compliqué ».
L’étape 1 lit le flux et repère les items que vous n’avez pas encore traités, en vous appuyant sur le guid de l’item. L’étape 2 poste l’URL de l’enclosure sur POST /v1/transcriptions avec le champ audio_url ; la réponse 202 vous donne un id de job. L’étape 3 est celle qu’on oublie : stockez ce job id dans votre table à côté de votre propre identifiant d’épisode. C’est ce qui rend le processus reprenable si votre worker redémarre.
L’étape 4 est le suivi : vous interrogez GET /v1/transcriptions/{id} jusqu’à ce que status vaille completed ou failed. Cela s’écrit très bien comme une boucle qui repasse sur les jobs en attente à chaque exécution — un cron toutes les cinq minutes, ou un workflow GitHub Actions planifié, suffit largement pour un podcast qui publie une fois par semaine. L’étape 5 enregistre transcript et segments, puis marque l’épisode comme traité. Un job failed peut être relancé avec POST /v1/transcriptions/{id}/retry.
Le modèle de job décrit ici reste le bon outil pour un lot d’épisodes : vous découplez la soumission du suivi, et un worker qui redémarre reprend là où il en était. Si vous traitez les épisodes un par un dans un script, POST /v1/transcribe est plus court à écrire — il attend la transcription et vous la renvoie directement, sans job id à stocker ni boucle à maintenir.
Pourquoi cette API
Reprenable par construction
Le job id est persistant : votre worker peut mourir entre le POST et la fin du traitement, la reprise consiste juste à réinterroger le job.
Polling assumé
Pas de webhook, donc pas d’endpoint public à exposer, pas de signature à vérifier, pas de rejeu à gérer. Un cron qui repasse sur les jobs en attente suffit.
Relance explicite
Un épisode en échec (média momentanément indisponible) se relance avec POST /v1/transcriptions/{id}/retry, sans recréer de job.
Tarifs lisibles
Questions fréquentes
Y a-t-il des webhooks pour être notifié de la fin ?+
Non, et pour un flux RSS vous n’en avez pas besoin. Deux options : POST /v1/transcribe attend la transcription et vous la renvoie directement, ce qui convient à un script qui traite les épisodes un par un ; ou vous gardez le modèle de job et repassez périodiquement sur GET /v1/transcriptions/{id} jusqu’à completed ou failed, ce qui reste le schéma le plus robuste pour un lot d’épisodes traité par cron.
À quelle fréquence interroger un job ?+
Toutes les cinq à dix secondes pendant un traitement actif, ou à chaque exécution de votre cron si vous traitez par lots. La limite de débit est de 120 requêtes par minute et par clé sur le plan Pro.
Comment éviter de transcrire deux fois le même épisode ?+
Gardez une table qui associe le guid de l’item RSS au job id renvoyé, et n’en créez un nouveau que pour les guid inconnus. Sur une source publique déjà transcrite, le cache évite de toute façon une refacturation.
Comment lister mes jobs en cours ?+
GET /v1/transcriptions accepte page, per_page et api_key_id. Pratique pour réconcilier après un incident, ou pour dédier une clé à ce pipeline et n’en voir que les jobs.
Que faire si un épisode échoue ?+
Le job passe en status failed avec un champ error. POST /v1/transcriptions/{id}/retry relance le traitement sur le même job, sans que vous ayez à modifier votre référence en base.
Autres façons d'intégrer l'API
Essai gratuit, sans carte bancaire
Générez une clé API et transcrivez votre première source en moins d'une minute. Quota mensuel gratuit pour tester en conditions réelles.
Commencer avec l'API