Aller au contenu principal
videas.comCréer un ticketOuvrir l'app

Envoyer avec l'API REST

Pilotez le protocole d'envoi reprenable TUS en HTTP simple — créez la session, transférez le fichier par chunks, et reprenez après une interruption.

Mis à jour le 28 août 2026uploadrestapitusgros-fichiers

Pas de SDK ? Vous pouvez piloter le flux d’envoi reprenable vous-même en HTTP simple. C’est le protocole TUS : créer une session, puis envoyer les octets par chunks (PATCH). C’est exactement ce que font les SDK en interne — préférez-les si vous le pouvez.

Tous les appels utilisent votre clé API (Authorization: Bearer sk_…) et la portée Write Assets, contre l’URL de base https://api.videas.com.

Étape 1 — créer la session d’envoi

POST /upload/ avec les en-têtes TUS. Upload-Metadata est une liste séparée par des virgules de paires clé <base64(valeur)> ; filename et workspace_uid sont requis (optionnels : asset_name, description, parent_folder_uid, content_type).

# echo -n "cours.mp4" | base64  → Y291cnMubXA0
# echo -n "ws_123"    | base64  → d3NfMTIz
curl -i -X POST https://api.videas.com/api/external/v1/upload/ \
  -H "Authorization: Bearer $VIDEAS_API_KEY" \
  -H "Tus-Resumable: 1.0.0" \
  -H "Upload-Length: 734003200" \
  -H "Upload-Metadata: filename Y291cnMubXA0,workspace_uid d3NfMTIz"

La réponse 201 porte un en-tête Location (où envoyer les octets) et un corps avec asset_uid (utilisable immédiatement) et expires_at :

{ "uid": "…", "location": "/api/external/v1/upload/<session>", "asset_uid": "ast_…", "total_size": 734003200, "expires_at": "…" }

Si location est relatif (comme ci-dessus), résolvez-le contre l’URL de base : https://api.videas.com/api/external/v1/upload/<session>.

Étape 2 — transférer le fichier par chunks

Envoyez les octets avec une ou plusieurs requêtes PATCH. Chaque requête :

  • porte Upload-Offset (nombre d’octets déjà envoyés — commence à 0),
  • utilise Content-Type: application/offset+octet-stream,
  • ne doit pas dépasser 50 Mio de corps.
# Premier chunk : octets 0 .. 50 Mio
curl -i -X PATCH "https://api.videas.com/api/external/v1/upload/<session>" \
  -H "Authorization: Bearer $VIDEAS_API_KEY" \
  -H "Tus-Resumable: 1.0.0" \
  -H "Upload-Offset: 0" \
  -H "Content-Type: application/offset+octet-stream" \
  --data-binary @chunk-0.bin

Chaque réponse 204 renvoie le nouvel Upload-Offset — utilisez-le comme offset du chunk suivant, et répétez jusqu’à avoir envoyé Upload-Length octets. Au dernier chunk, la réponse inclut X-Checksum-Blake3.

Une petite boucle, en pseudo-code :

offset = 0
while offset < total:
    end   = min(offset + CHUNK, total)          # CHUNK ≤ 50 Mio
    PATCH location, Upload-Offset: offset, body = bytes[offset:end]
    offset = response.headers["Upload-Offset"]  # offset autoritaire du serveur

Reprendre après une interruption

Si un PATCH échoue ou que la connexion tombe, demandez au serveur où il en est avec un HEAD, puis reprenez à partir de là :

curl -I "https://api.videas.com/api/external/v1/upload/<session>" \
  -H "Authorization: Bearer $VIDEAS_API_KEY" -H "Tus-Resumable: 1.0.0"
# → Upload-Offset: 314572800   (reprendre le PATCH à cet offset)

Un 409 Conflict sur un PATCH signifie que votre Upload-Offset ne correspond pas à celui du serveur ; l’en-tête Upload-Offset de la réponse donne le bon. Les sessions expirent après 24 heures — recommencez avec une nouvelle session au-delà.

Après l’envoi : attendre le traitement

L’asset_uid existe immédiatement, mais la vidéo est traitée de façon asynchrone. Interrogez-la jusqu’à ce qu’elle soit prête :

curl https://api.videas.com/api/external/v1/assets/ast_.../ \
  -H "Authorization: Bearer $VIDEAS_API_KEY"
# → { "status": "ready", … }  (ne pas lire/intégrer avant "ready")

Étapes suivantes