Skip to main content
POST
Finalisez un envoi d’image de référence qui vous appartient à l’aide des numéros de parties et des ETags des requêtes PUT. Vérifie la taille du fichier stocké. Utilisez le fileKey renvoyé comme référence pour la génération.

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: images: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. La clé de référence finalisée vous appartenant et son URL de lecture, renvoyées uniquement lorsque le nombre d’octets stockés correspond exactement à la taille de fichier déclarée. Utilisez fileKey, et non readUrl, dans les arguments de génération.

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 images:write ; aucune autorisation d’envoi supplémentaire n’est nécessaire.
  • uploadId est l’UUID provenant de initialize. parts contient exactement les 1–2 parties exigées par la session. Chaque partie possède un entier partNumber de 1 à 2 et une chaîne etag de 1–256 caractères issue de sa réponse PUT réussie.
  • Tous les numéros de partie doivent être présents et uniques. Les parties sont triées avant la finalisation ; les ETags sont normalisés en valeurs entre guillemets. Vous pouvez conserver les guillemets des ETag renvoyés par le stockage.
  • La taille réelle de l’objet finalisé en octets est vérifiée par rapport à fileSize et à la limite de 8 MiB. Une taille absente, différente ou excessive entraîne la suppression de l’objet et de la session active, et renvoie UPLOAD_SIZE_MISMATCH.
  • Transmettez fileKey dans referenceImageKey pour images_generate. Les fichiers de référence finalisés peuvent être réutilisés pour les générations suivantes d’images ou de miniatures du même utilisateur ; la génération ne consomme pas la référence.
  • 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.
  • La finalisation ferme la session multipartie. Réessayez la finalisation avec le requestId d’origine pour récupérer le résultat enregistré ; une nouvelle requête de finalisation pour cet uploadId fermé renvoie Upload not found. Cette action ne renvoie aucune échéance de conservation de la référence.

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