WizCut API
Automatise le montage de podcasts multicam avec l'API WizCut : envoi, traitement et rendu par programmation.
L’API WizCut te permet d’automatiser le montage de podcasts multicam. Tu envoies tes angles de caméra, WizCut détecte les intervenants, trouve qui est sur quelle caméra et génère les coupes, tu peux optionnellement les relire dans un éditeur en ligne, et tu récupères la vidéo rendue via webhook.
Authentification
Crée une clé API sur wizcut.com/settings. Inclus-la dans chaque requête :
Authorization: Bearer wc_live_your_key_here
Les clés peuvent être révoquées à tout moment depuis la page de paramètres.
Créer un job
POST /api/jobs
{
"sources": [
{ "label": "Camera 1", "kind": "video", "ext": "mp4", "fileSize": 2147483648 },
{ "label": "Camera 2", "kind": "video", "ext": "mp4", "fileSize": 1932735283 },
{ "label": "Mic mix", "kind": "audio", "ext": "wav" }
],
"callbackUrl": "https://your-server.com/webhook",
"review": true,
"autoMap": "confident",
"silence": { "mode": "tighten" }
}
Champs :
| Champ | Type | Description |
|---|---|---|
sources | array | Angles de caméra ou fichiers audio, 12 maximum par job. Il faut au moins deux sources vidéo pour qu’un job puisse être traité. Chaque entrée a un label, un kind optionnel ("video" ou "audio", par défaut "video"), un ext optionnel (mp4, mov, webm, mkv, wav, mp3, m4a ou aac ; par défaut "mp4" pour la vidéo, "wav" pour l’audio) et un fileSize optionnel en octets. |
callbackUrl | string | Optionnel. URL qui reçoit les notifications webhook : voir Webhooks. |
review | boolean | Par défaut true. Quand true, le job se met en pause à « ready » pour qu’un humain relise les coupes avant le render. Quand false, le render démarre automatiquement dès que le mapping des intervenants est soumis, que ce soit par une personne, par ton code ou par WizCut lui-même. |
autoMap | string | Par défaut "confident". Indique si WizCut a le droit de décider seul qui est sur quelle caméra : "off", "confident" ou "always". Voir Mapping automatique des caméras. |
silence | object | Optionnel. Suppression automatique des pauses : voir la section Suppression des silences. Si absent, c’est désactivé. |
Tu ne peux pas passer le mapping des intervenants (tracks) ici : les IDs de source n’existent qu’une fois le job créé, donc il n’y a encore rien à quoi rattacher un intervenant. Une liste tracks qui nomme des intervenants est rejetée avec un 400 et "code": "TRACKS_ON_CREATE". Utilise autoMap, ou mappe les intervenants via l’API une fois la détection terminée.
Passe fileSize pour chaque fichier dont tu connais la taille. Les fichiers de plus de 100 Mo passent alors en upload multipart : tu peux envoyer les parties en parallèle, retenter une partie isolée, et c’est la seule façon d’envoyer des fichiers de plus de 5 Go. Sans fileSize, chaque fichier part en un seul PUT présigné.
Réponse :
{
"jobId": "uuid",
"uploads": {
"source-uuid-1": {
"method": "multipart",
"uploadId": "...",
"key": "sources/uuid/source-uuid-1.mp4",
"partSize": 52428800,
"partCount": 41,
"urls": ["https://presigned-part-1-url...", "https://presigned-part-2-url...", "..."]
},
"source-uuid-3": {
"method": "put",
"url": "https://presigned-upload-url..."
}
},
"audioUploads": { "...": "..." }
}
uploads est indexé par les IDs de source attribués par WizCut, dans le même ordre que ton tableau sources. Tu peux ignorer audioUploads : c’est utilisé par les apps WizCut, qui envoient une piste audio extraite avant la vidéo.
Uploader les fichiers
Pas besoin d’en-tête d’auth pour les URL présignées : elles s’authentifient toutes seules.
"method": "put" : envoie le fichier entier en PUT vers url, dans l’heure qui suit :
curl -X PUT -T mic-mix.wav "https://presigned-upload-url..."
"method": "multipart" : découpe le fichier en morceaux de partSize octets (le dernier est plus court) et envoie le morceau n en PUT vers l’URL de la partie n.
-
urlscontient les URL des premières parties (urls[0]correspond à la partie 1). Demande les suivantes au fur et à mesure, 16 maximum par requête :POST /api/jobs/{jobId}/sources/{sourceId}/parts{ "uploadId": "...", "partNumbers": [5, 6, 7, 8] }La réponse associe les numéros de partie à des URL :
{ "urls": { "5": "https://...", "6": "https://..." } }. Les URL de partie sont valables deux heures, donc récupère-les juste avant de t’en servir. -
Une fois toutes les parties envoyées, termine l’upload :
POST /api/uploads/complete{ "key": "sources/uuid/source-uuid-1.mp4", "uploadId": "..." }
Pour abandonner un upload, envoie le même corps à POST /api/uploads/abort.
Lancer le traitement
POST /api/jobs/{jobId}/process
Appelle cet endpoint une fois que tous les fichiers sont envoyés. Ça démarre le pipeline : sync audio, détection des intervenants, render proxy, mapping des caméras et génération des coupes. La requête répond immédiatement, le traitement se fait en asynchrone.
Corps optionnel :
{ "diarizeSourceIds": ["source-uuid-3"] }
diarizeSourceIds choisit les sources que WizCut écoute pour la détection des intervenants. Si tu l’omets, WizCut utilise tes sources audio, ou la première source s’il n’y en a pas. Choisis les sources où tout le monde s’entend le mieux : une caméra avec un micro coupé ou trop loin donne un job sans aucune coupe.
Réponse :
{ "jobId": "uuid", "status": "syncing" }
Lister les jobs
GET /api/jobs
Retourne { "jobs": [...] } avec tes 50 jobs les plus récents, du plus récent au plus ancien. Chacun contient id, title, status, created_at et updated_at.
Vérifier le statut d’un job
GET /api/jobs/{jobId}
Réponse :
{
"job": {
"id": "uuid",
"status": "complete",
"sources": [...],
"tracks": [...],
"turns": [...],
"cuts": [...],
"removed_ranges": [...],
"camera_map": {...},
"output_url": "https://presigned-download-url...",
"error_message": null
},
"sourceUrls": { "source-uuid-1": "https://..." },
"audioUrl": "https://..."
}
Le job en lui-même se trouve sous job. Les URL signées de la réponse (output_url, sourceUrls, audioUrl) sont signées à nouveau à chaque requête, donc récupère le job à nouveau plutôt que de les stocker.
camera_map est la proposition de WizCut pour savoir qui est sur quelle caméra : voir La camera map. Elle vaut null tant qu’elle n’a pas été calculée.
Valeurs de statut :
| Statut | Signification |
|---|---|
created | Job créé, en attente des uploads |
uploading | En attente de la fin des uploads (par exemple après la réouverture d’un job en échec) |
syncing | Alignement audio entre les sources |
diarizing | Détection des intervenants |
mapping | Intervenants détectés. WizCut cherche encore qui est sur quelle caméra, ou une personne (ou ton agent) doit le confirmer |
ready | Coupes générées, prêtes pour la relecture ou le render |
rendering | Render final en cours |
complete | Render terminé, output_url disponible |
approved | Output validé par un humain |
failed | Quelque chose s’est mal passé, voir error_message |
Supprimer un job
DELETE /api/jobs/{jobId}
Supprime le job et tous ses fichiers : uploads, proxys, audio de détection des intervenants et rendu final. Ça marche quel que soit le statut ; si une étape tourne encore, son résultat est nettoyé dès qu’elle se termine. Les minutes déjà utilisées ne sont pas recréditées. Renvoie { "ok": true }, ou 404 si le job n’existe pas ou ne t’appartient pas.
Webhooks
Si tu fournis un callbackUrl, WizCut envoie une requête POST en JSON quand un job atteint un des statuts ci-dessous. WizCut tente chaque livraison jusqu’à trois fois et attend jusqu’à 10 secondes que ton endpoint réponde.
Les webhooks ne sont pas encore signés, donc traite-les comme un simple signal pour aller chercher le job via GET /api/jobs/{jobId} plutôt que de faire confiance à leur contenu. Fais aussi du polling en secours, au cas où une livraison se perdrait.
Webhook « mapping » (une personne doit confirmer qui est sur quelle caméra) :
{
"jobId": "uuid",
"status": "mapping",
"reviewUrl": "https://wizcut.com/jobs/uuid/edit?reviewToken=...",
"speakers": ["SPEAKER_00", "SPEAKER_01"],
"cameraMap": {
"version": 1,
"speakers": ["SPEAKER_00", "SPEAKER_01"],
"unassignedSpeakers": ["SPEAKER_01"],
"droppedSpeakers": [],
"cameras": [
{ "sourceId": "source-uuid-1", "kind": "closeup", "confidence": "high", "speakers": ["SPEAKER_00"], "...": "..." },
{ "sourceId": "source-uuid-2", "kind": "closeup", "confidence": "low", "speakers": ["SPEAKER_01"], "...": "..." }
]
}
}
Envoie quelqu’un sur la reviewUrl pour mapper les intervenants aux sources caméra et relire les coupes, ou mappe-les via l’API. Les liens de relecture sont valables 72 heures. speakers liste les intervenants détectés, du plus bavard au moins bavard.
cameraMap est la proposition de WizCut, au même format que camera_map sur le job : voir La camera map. Elle est absente quand il n’y a pas encore de proposition.
Le moment où ce webhook arrive dépend de autoMap :
"confident"ou"always": le job attend en « mapping » sans webhook pendant que WizCut cherche les caméras, ce qui prend quelques minutes une fois les proxys prêts. Ensuite, soit il mappe les caméras lui-même et le prochain webhook que tu reçois est « ready », soit il envoie « mapping » avec la proposition en pièce jointe. Si WizCut n’arrive pas à calculer de proposition (par exemple parce qu’un proxy a échoué), « mapping » part sanscameraMap, au plus tard environ 30 minutes après la détection des intervenants."off": « mapping » part juste après la détection des intervenants, en général sanscameraMap. La proposition apparaît dansGET /api/jobs/{jobId}quelques minutes plus tard.
Webhook « ready » (mapping soumis, par une personne, ton code ou WizCut, et coupes générées) :
{
"jobId": "uuid",
"status": "ready",
"reviewUrl": "https://wizcut.com/jobs/uuid/edit?reviewToken=..."
}
Webhook « complete » (render terminé) :
{
"jobId": "uuid",
"status": "complete",
"outputUrl": "https://presigned-download-url..."
}
Webhook « approved » (output validé via l’UI de relecture) :
{
"jobId": "uuid",
"status": "approved",
"outputUrl": "https://presigned-download-url..."
}
Webhook « failed » (le job a échoué, à n’importe quelle étape) :
{
"jobId": "uuid",
"status": "failed",
"error": "description of what went wrong",
"failedAtStatus": "syncing"
}
error contient le même message que error_message dans GET /api/jobs/{jobId}, et failedAtStatus indique l’étape qui a échoué, par exemple syncing, diarizing ou rendering. Pour la plupart des échecs de sync, de détection des intervenants et de render, WizCut refait d’abord une tentative tout seul : si tu reçois ce webhook, c’est que la deuxième n’a pas marché non plus.
Le outputUrl des webhooks « complete » et « approved » est valable sept jours après la fin du render. GET /api/jobs/{jobId} retourne toujours un output_url fraîchement signé.
Mapping des intervenants et relecture (human-in-the-loop)
Après la détection des intervenants, le job passe en statut « mapping ». Les intervenants détectés doivent être associés aux sources caméra : cette détection identifie quand quelqu’un parle, mais pas sur quelle caméra il est.
WizCut essaie de le deviner pour toi. Les gens bougent quand ils parlent : ils gesticulent, hochent la tête, se penchent. WizCut compare donc la parole de chaque intervenant avec le mouvement de chaque caméra et propose qui est sur laquelle. Tu décides jusqu’où il peut aller seul avec autoMap.
Quand il faut une personne, WizCut envoie le webhook « mapping ». Il inclut une reviewUrl, un lien signé vers l’éditeur WizCut. Envoie quelqu’un là-bas. Dans l’éditeur, il peut :
- Vérifier quel intervenant est sur quelle caméra (les caméras dont WizCut est sûr sont déjà sélectionnées)
- Prévisualiser et modifier les coupes générées automatiquement
- Cliquer sur « Render » quand c’est bon (si
review: true, le comportement par défaut) - Cliquer optionnellement sur « Approve » après avoir relu l’output rendu
Avec review: false, le render démarre automatiquement dès que le mapping des intervenants est soumis. Personne ne relit les coupes avant le render.
Mapping automatique des caméras
Règle autoMap à la création du job :
| Mode | Ce que fait WizCut | À choisir quand |
|---|---|---|
"off" | Ne mappe jamais les caméras seul. Envoie « mapping » juste après la détection des intervenants ; la proposition apparaît sur le job quelques minutes plus tard, pour qu’une personne ou ton agent s’en serve. | Une personne relit de toute façon le mapping. |
"confident" | Par défaut. Mappe les caméras seul quand il est sûr d’avoir trouvé un gros plan de chaque intervenant, puis passe en « ready ». Sinon, envoie « mapping » avec la proposition. Un plan large ou un plan à deux sert dans le montage, mais ne compte jamais comme la caméra propre d’un intervenant. | La plupart des intégrations. WizCut ne se manifeste que quand il a besoin d’aide. |
"always" | N’attend pas de personne. Utilise les réponses dont il est sûr, puis ses réponses probables, et place ceux qui restent sur les caméras libres selon leur temps de parole. Il n’envoie « mapping » que s’il ne peut pas du tout calculer de proposition (par exemple parce qu’un proxy a échoué). | Les pipelines entièrement automatiques, qui préfèrent un montage deviné à un job bloqué. |
« Sûr de chaque intervenant » veut dire : tous ceux qui ont au moins une minute de parole sont sur une caméra à laquelle WizCut a répondu avec une confiance high. Les caméras dont il n’est pas sûr n’ont aucun intervenant, donc le montage ne coupe pas vers elles. Corrige ça dans l’éditeur si tu veux qu’elles servent.
Prépare-toi à ce que « confident » fasse intervenir une personne assez souvent. Il se retient sur les rushes où le mouvement ne suit pas un seul intervenant : plateaux TV avec flux commutés, événements, caméras à l’épaule ou pilotées. Il lui faut aussi environ 20 minutes de conversation pour être sûr, donc les clips courts finissent en général en « mapping ». Dans nos tests jusqu’ici, WizCut n’a jamais mis un intervenant sur la mauvaise caméra quand il disait être sûr, mais l’échantillon reste petit.
Combinés avec review: false, "confident" et "always" permettent à un job de se rendre sans que personne le regarde. C’est le but pour les pipelines automatiques ; si tu veux qu’une personne voie chaque montage, garde review: true.
La camera map
La proposition est sur le job sous camera_map (et dans le webhook « mapping » sous cameraMap). Elle vaut null tant qu’elle n’est pas calculée, soit quelques minutes après la fin des proxys. En voilà une pour une émission à deux, avec un gros plan de chaque personne et un plan à deux :
{
"version": 1,
"computedAt": "2026-10-01T09:42:17.000Z",
"speakers": ["SPEAKER_00", "SPEAKER_01"],
"unassignedSpeakers": [],
"droppedSpeakers": ["SPEAKER_02"],
"cameras": [
{
"sourceId": "source-uuid-1",
"kind": "closeup",
"confidence": "high",
"speakers": ["SPEAKER_00"],
"z": { "SPEAKER_00": 11.5, "SPEAKER_01": 0.9 },
"lagErrorS": { "SPEAKER_00": 0.1, "SPEAKER_01": 41.6 }
},
{
"sourceId": "source-uuid-2",
"kind": "closeup",
"confidence": "high",
"speakers": ["SPEAKER_01"],
"z": { "SPEAKER_01": 12.4, "SPEAKER_00": 1.3 },
"lagErrorS": { "SPEAKER_01": 0.2, "SPEAKER_00": 63.0 }
},
{
"sourceId": "source-uuid-3",
"kind": "twoshot",
"confidence": "high",
"speakers": ["SPEAKER_01", "SPEAKER_00"],
"positions": { "left": "SPEAKER_01", "right": "SPEAKER_00" },
"z": { "SPEAKER_00": 6.8, "SPEAKER_01": 5.2 },
"lagErrorS": { "SPEAKER_00": 0.3, "SPEAKER_01": 0.4 }
}
]
}
Par caméra :
| Champ | Description |
|---|---|
sourceId | Une des sources vidéo du job. |
kind | Ce que montre la caméra : closeup (une personne), twoshot (deux personnes côte à côte), wide (trois personnes), multi (plusieurs personnes, l’une après l’autre : en général une caméra pilotée ou commutée) ou unknown. |
confidence | high (WizCut est sûr), low (une réponse probable, pas certaine) ou none (aucune réponse). |
speakers | Qui la caméra montre. Vide quand confidence vaut none. Pour les plans à deux et les plans larges, de gauche à droite. |
positions | Plans à deux et plans larges uniquement : qui est à left, middle et right du cadre. |
reason | Vaut no_motion quand une caméra n’a pas pu être analysée du tout. |
z, lagErrorS | Chiffres de diagnostic par intervenant : à quel point le mouvement de la caméra suit la parole de cette personne, et de combien de secondes la meilleure correspondance est décalée. Pratique pour déboguer, pas quelque chose sur quoi bâtir. |
Au niveau supérieur :
| Champ | Description |
|---|---|
speakers | Les intervenants que WizCut a jugés : tous ceux qui ont au moins une minute de parole. |
unassignedSpeakers | Intervenants jugés qui ne sont sur aucune caméra high. Si la liste n’est pas vide, « confident » laisse la décision à une personne. |
droppedSpeakers | Intervenants avec trop peu de parole pour être jugés, en général une étiquette parasite ou une courte interjection. WizCut ne les place sur aucune caméra. |
Pour accepter la proposition telle quelle, transforme chaque caméra de confiance en track (son sourceId et ses speakers) et envoie-le.
Mapper les intervenants via l’API
Si tu sais déjà qui est assis devant quelle caméra, ou que ton agent a vérifié la proposition, soumets le mapping toi-même pendant que le job est en statut « mapping » :
POST /api/jobs/{jobId}/tracks
{
"tracks": [
{ "sourceId": "source-uuid-1", "speakers": ["SPEAKER_00"] },
{ "sourceId": "source-uuid-2", "speakers": ["SPEAKER_01"] }
]
}
Utilise les noms d’intervenants du webhook « mapping » (ou les turns de GET /api/jobs/{jobId}) avec les IDs de tes sources vidéo. Une même caméra peut montrer plusieurs intervenants. WizCut génère alors les coupes, passe le job en « ready », envoie le webhook « ready » et, avec review: false, démarre le render. La réponse contient les nouvelles cuts.
Chaque sourceId doit être une des sources vidéo du job ; sinon tu reçois un 400 avec "code": "UNKNOWN_SOURCE". Tu peux soumettre pendant que WizCut cherche encore les caméras : le premier arrivé gagne. Si le mapping a déjà été soumis, par exemple automatiquement, tu reçois un 409 avec "code": "INVALID_STATUS".
Avancé : corriger un mapping une fois les coupes créées. Quand le job est en « ready » ou « complete », le même endpoint peut encore changer le mapping, mais il ne génère plus les coupes à ta place : envoie les cuts corrigées avec tracks (et éventuellement removedRanges), sinon tu reçois un 400 avec "code": "CUTS_REQUIRED". WizCut enregistre les deux ensemble, donc un recut ultérieur utilise le mapping corrigé. Il n’envoie pas de webhook et ne lance pas de render : déclenche-en un si tu veux une nouvelle sortie. L’éditeur WizCut fait tout ça pour toi quand quelqu’un y corrige un mapping.
Suppression des silences
WizCut peut automatiquement raccourcir ou supprimer les longues pauses avant de générer les coupes. Ça se passe en premier, donc le changement de caméra est décidé sur la conversation resserrée : tu n’obtiens jamais une coupe vers une caméra qui perd immédiatement la majorité de son temps à l’écran à cause d’une pause supprimée.
Active-la avec le champ silence à la création d’un job :
{ "silence": { "mode": "tighten" } }
Modes :
| Mode | Comportement |
|---|---|
off | Garde toutes les pauses telles qu’enregistrées (par défaut si silence est absent). |
tighten | Raccourcit les longues pauses à un battement naturel (~0,7 s). Recommandé : garde à la conversation son côté humain. |
remove | Coupe les longues pauses presque entièrement, en laissant juste assez de padding pour éviter de couper des mots. |
Réglages fins optionnels (les valeurs par défaut marchent bien pour la plupart des enregistrements) :
| Champ | Défaut | Plage | Description |
|---|---|---|---|
minPauseSec | 1.5 | 0,3–10 | Seules les pauses plus longues que ça sont touchées. |
keepPauseSec | 0.7 | 0–3 | Le battement laissé à la place d’une pause resserrée (mode tighten uniquement). |
paddingSec | 0.25 | 0–1 | Marge de sécurité gardée autour de la parole à chaque intervalle supprimé. |
La détection est prudente : une pause n’est supprimée que si la détection des intervenants et une analyse de l’énergie audio s’accordent tous les deux à dire que c’est calme, donc les rires et autres moments non-parlés survivent.
L’objet job (GET /api/jobs/{jobId}) inclut removed_ranges (les intervalles supprimés en temps source, sous la forme { startMs, endMs }) en plus de cuts. Le render final saute ces intervalles ; l’éditeur de relecture les affiche comme des sections hachurées et restaurables.
Modifie ça après le traitement avec l’endpoint recut :
POST /api/jobs/{jobId}/recut
{ "silence": { "mode": "remove", "minPauseSec": 1.0 } }
Recut régénère les coupes et les intervalles supprimés à partir des intervenants déjà détectés, sans nouveau traitement, donc ça répond immédiatement avec les nouveaux cuts, removedRanges et savedMs (de combien la sortie devient plus courte). Passe { "mode": "off" } pour désactiver à nouveau la suppression des silences ; omets silence entièrement pour garder le réglage déjà enregistré du job.
Note sur la facturation : l’usage est mesuré en minutes d’entrée (les rushes que tu uploades), donc la suppression des silences ne change pas ce que coûte un job, elle rend juste la sortie plus resserrée.
Avancé : contrôle programmatique des coupes
Pour les pipelines entièrement automatisés qui contournent l’UI, laisse WizCut mapper les caméras ou mappe les intervenants via l’API, puis gère toi-même les coupes et le render. Ces endpoints fonctionnent tant que le job est en « ready » ou « complete » :
Modifier les coupes :
PATCH /api/jobs/{jobId}/cuts
{
"cuts": [
{ "startMs": 0, "endMs": 5000, "sourceId": "source-uuid-1" },
{ "startMs": 5000, "endMs": 12000, "sourceId": "source-uuid-2" }
]
}
Ce même endpoint accepte aussi removedRanges (un tableau de { startMs, endMs }) pour éditer directement les intervalles de suppression de silences, par exemple pour restaurer une pause que la passe automatique a supprimée. Tu peux envoyer cuts, removedRanges, ou les deux.
Déclencher le render :
POST /api/jobs/{jobId}/render
Marche depuis « ready », ou depuis « complete » pour relancer un render après avoir modifié les coupes. Retourne { "jobId": "uuid", "status": "rendering" }, ou un 409 avec "code": "NO_CUTS" si le job n’a aucune coupe à render.
Valider l’output :
POST /api/jobs/{jobId}/approve
Ne marche qu’une fois le job « complete ». Le fait passer en « approved » et envoie le webhook « approved ».
Réponses d’erreur
Tous les endpoints retournent les erreurs dans ce format :
{ "error": "Description of what went wrong" }
Certaines erreurs incluent aussi un code exploitable par un programme :
| Code | HTTP | Signification |
|---|---|---|
TRACKS_ON_CREATE | 400 | POST /api/jobs a reçu un mapping des intervenants. Laisse tracks de côté et utilise autoMap, ou règle le mapping plus tard. |
UNKNOWN_SOURCE | 400 | Un track nomme un sourceId qui n’est pas une des sources vidéo du job. |
CUTS_REQUIRED | 400 | Changer le mapping une fois les coupes créées demande aussi les cuts mises à jour. |
NOT_ENOUGH_VIDEOS | 400 | Le job a besoin d’au moins deux sources vidéo pour être traité. |
QUOTA_EXCEEDED | 403 | Tu as épuisé tes minutes. |
INVALID_STATUS | 409 | Le statut du job ne permet pas cette action, par exemple parce que son mapping a déjà été soumis. |
NO_CUTS | 409 | Il n’y a aucune coupe à render. |
Codes HTTP courants :
| Code | Signification |
|---|---|
| 400 | Requête invalide (par exemple moins de deux sources vidéo au moment du traitement) |
| 401 | Clé API manquante ou invalide |
| 403 | Quota dépassé |
| 404 | Job introuvable ou qui ne t’appartient pas |
| 409 | Transition de statut invalide (ex. render d’un job qui n’est pas « ready ») |
| 500 | Erreur serveur |
| 502 | Un service de traitement a rejeté le job ou n’a pas réussi à démarrer |
| 503 | Service indisponible |
Déroulement complet
Voilà le chemin nominal complet pour un agent IA ou une automatisation :
# 1. Créer un job avec deux caméras (fichiers jusqu'à 5 Go chacun,
# passe fileSize pour obtenir des uploads multipart au-delà)
JOB=$(curl -s -X POST https://wizcut.com/api/jobs \
-H "Authorization: Bearer wc_live_your_key" \
-H "Content-Type: application/json" \
-d '{
"sources": [
{"label": "Camera 1", "kind": "video"},
{"label": "Camera 2", "kind": "video"}
],
"callbackUrl": "https://your-server.com/webhook"
}')
JOB_ID=$(echo $JOB | jq -r '.jobId')
# 2. Envoyer les fichiers vidéo vers les URL présignées
curl -X PUT -T camera1.mp4 "$(echo $JOB | jq -r '.uploads | to_entries[0].value.url')"
curl -X PUT -T camera2.mp4 "$(echo $JOB | jq -r '.uploads | to_entries[1].value.url')"
# 3. Lancer le traitement
curl -s -X POST "https://wizcut.com/api/jobs/$JOB_ID/process" \
-H "Authorization: Bearer wc_live_your_key"
# 4. Attendre le prochain webhook. Avec l'autoMap par défaut ("confident") :
# - { status: "ready", reviewUrl: "..." } : WizCut a mappé les caméras tout seul
# - { status: "mapping", reviewUrl: "...", speakers: [...], cameraMap: {...} }
# : il n'était pas sûr. Envoyer quelqu'un sur la reviewUrl pour confirmer les caméras
# (ou envoyer le mapping toi-même en POST vers /api/jobs/$JOB_ID/tracks)
# 5. La personne relit et retouche les coupes → clique sur Render dans l'éditeur
# Attendre le webhook : { status: "complete", outputUrl: "..." }
# 6. Télécharger la vidéo rendue depuis outputUrl
Entièrement automatique (autoMap: "always", review: false) :
# Comme ci-dessus, mais avec "autoMap": "always" et "review": false à l'étape 1
# WizCut mappe les caméras lui-même, même quand il n'est pas sûr,
# et lance le render juste après, sans aucune intervention humaine
# Tu reçois : { status: "ready", ... }, puis { status: "complete", outputUrl: "..." }
Intégrations
Tu préfères éviter le code ? Tu peux piloter l’API WizCut depuis des plateformes d’automatisation sans écrire aucune des requêtes ci-dessus.
n8n
On maintient une intégration n8n officielle avec le nœud communautaire vérifié @wizcut/n8n-nodes-wizcut. Installe-le depuis Settings → Community Nodes dans n8n (il est vérifié, donc disponible sur n8n Cloud aussi).
Il embarque deux nœuds :
- WizCut : actions pour Create Job, Get Job, Start Processing, Start Render et Approve.
- WizCut Trigger : un déclencheur webhook qui lance ton workflow à chaque changement de statut d’un job (mapping, ready, complete, approved).
Pointe l’URL webhook du trigger vers le callbackUrl de ton job et tu obtiens un pipeline entièrement événementiel : ping Slack quand WizCut a besoin que quelqu’un confirme qui est sur quelle caméra, démarrage automatique du render quand les coupes sont prêtes, envoi du lien de téléchargement quand l’épisode est terminé. Les deux nœuds fonctionnent aussi comme outils pour les agents IA n8n.
Tu veux démarrer vite ? Récupère le template prêt à l’emploi : Suis et gère le statut de montage de tes podcasts avec WizCut et Slack.
Plus de plateformes
Des intégrations Make.com et Zapier sont dans la roadmap. Tu bosses sur une autre plateforme, ou tu veux un template de workflow pour ta config précise ? Contacte le support WizCut. Les demandes de fonctionnalités sont les bienvenues.