Skip to main content
POST
Obtenez des URL PUT signées pour un envoi d’image de référence qui vous appartient. Une image de 8 MiB comporte au maximum deux parties. Conservez l’ETag renvoyé par chaque requête PUT pour upload_complete.

​
Authentification et autorisations

​
string
requis
Envoyez une clé API VoiceCheap dans cet en-tête. Authorization: Bearer avec la même clé API est également accepté. Les jetons d’accès OAuth sont acceptés uniquement par MCP, pas par cet endpoint REST.
Autorisations requises: thumbnails:write. Un abonnement payant actif est requis. Les autorisations ne modifient ni les rôles dans l’équipe, ni la propriété des ressources, ni les crédits média, ni les limites du forfait.

​
Paramètres

​
string
Facultatif au niveau du transport : le serveur injecte un identifiant avant la validation si ce champ est omis. Fournissez votre propre UUID v4 stable pour récupérer le résultat en toute sécurité si la réponse est perdue.Format: “uuid”. Motif: ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$.
​
string
requis
L’uploadId renvoyé par l’action upload_initialize de ce domaine.Format: “uuid”. Motif: ^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$.
​
array
requis
Liste de valeurs. Consultez le schéma d’entrée complet pour connaître la structure de ses éléments.Nombre minimal d’éléments: 1. Nombre maximal d’éléments: 2.
Le JSON Schema ci-dessous conserve les noms de champs exacts, les types imbriqués, les valeurs par défaut, les limites et les valeurs acceptées exposés par la découverte. Les règles supplémentaires entre champs figurent dans les notes de l’opération.

​
Idempotence

Utilisez un UUID v4 dans requestId ou dans l’en-tête HTTP Idempotency-Key pour chaque mutation. Après une erreur réseau, réutilisez le même identifiant avec des arguments identiques. Si les deux sont fournis, ils doivent correspondre. Rejouer une requête enregistrée ne répète pas l’opération et ne décompte pas un nouvel appel mensuel. Les requêtes en échec ou interrompues ne sont pas relancées automatiquement. Toute mutation peut renvoyer HTTP 202 lorsqu’une nouvelle tentative retrouve la même requête encore en cours, même si sa première exécution est habituellement synchrone. Si l’exécution est terminée mais que resultStored vaut false, une nouvelle tentative renvoie HTTP 200 avec l’état de la requête enregistrée, au lieu du résultat d’origine. Récupérez le résultat avec l’action d’historique, de résultat ou de téléchargement de son domaine.

​
Exemples de requêtes

Remplacez les exemples d’identifiants de ressources et de clés média par des valeurs renvoyées pour votre compte. Conservez le même identifiant de requête lorsque vous réessayez la même mutation.

​
Réponse

Une première exécution réussie renvoie HTTP 200 avec le résultat de l’opération sous data. Une nouvelle tentative peut renvoyer à la place l’état de la requête enregistrée. L’exemple présente une réponse possible, sans tous les champs facultatifs. Tableau d’URL PUT signées temporaires, une par numéro de partie distinct demandé. La réponse ne contient ni octets d’image, ni ETags, ni champs de taille par partie.

​
Champs du résultat

​
Récupérer et suivre cette requête

Utilisez le même identifiant, même après une perte de connexion. Si resultStored vaut false, récupérez le résultat avec l’action d’historique, de résultat ou de téléchargement correspondante. Ne lancez jamais une seconde génération uniquement pour vérifier l’avancement.
HTTP 200

​
Notes de l’opération

  • Nécessite thumbnails:write ; aucune portée d’envoi supplémentaire n’est requise.
  • uploadId est l’UUID provenant de initialize. partNumbers contient 1–2 entiers, chacun compris entre 1 et 2, et chaque partie doit exister pour le fileSize déclaré de cette session. Les numéros de partie demandés en double sont regroupés en une seule URL.
  • Envoyez les octets binaires bruts de chaque partie par PUT à chaque URL renvoyée. Content-Length est signé et doit correspondre exactement à min(partSize, fileSize - (partNumber - 1) × partSize). Pour l’exemple de 7 MiB, la partie 1 contient 5,242,880 octets et la partie 2, 2,097,152 octets. N’envoyez ni JSON, ni multipart/form-data, ni base64 à l’URL signée.
  • Conservez l’en-tête de réponse ETag de chaque PUT réussi et transmettez ces valeurs à thumbnails_upload_complete. Traitez les URL signées comme des accès privés et temporaires permettant l’envoi.
  • Seul un envoi appartenant à l’utilisateur connecté peut être signé, finalisé ou annulé. Ces alias acceptent uniquement les sessions JPG, PNG et WebP de 8 MiB maximum, même si la session a été créée via une autre famille d’envois.
  • La session d’envoi de production expire après 24 heures. Les URL signées des parties expirent après une heure. La finalisation et l’annulation suppriment la session active ; sign-parts et complete renvoient ensuite Upload not found. Aucune des deux réponses ne contient de champ expiresAt.
  • Utilisez un requestId UUID v4 ou l’en-tête HTTP Idempotency-Key, et réutilisez-le avec des entrées identiques lors des nouvelles tentatives. La couche d’intégration enregistre chaque modification et renvoie son état ou son résultat enregistré sans la réexécuter. Une requête échouée ou interrompue n’est pas automatiquement relancée.
  • Pour obtenir de nouvelles URL après leur expiration au bout d’une heure, tant que la session est encore active, appelez sign-parts avec un nouveau requestId. Une nouvelle tentative avec le même requestId renvoie le résultat enregistré, y compris les anciennes URL.

​
Utilisation

Chaque invocation réussie consomme un appel du quota mensuel API/MCP. Les crédits média et les quotas de génération propres à l’opération s’appliquent également.

​
Erreurs