Skip to main content
POST
Générez une image pour le compte connecté. Les mêmes quotas média et protections que dans l’application web s’appliquent. Conservez le generationId renvoyé et utilisez images_download pour récupérer l’image. Réutilisez requestId lorsque vous réessayez la même requête.

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
Valeur textuelle.Longueur minimale: 10. Longueur maximale: 1200.
string
Valeur textuelle.Valeurs acceptées: “square”, “landscape”, “portrait”. Valeur par défaut: “square”.
string
Clé d’un objet JPG, PNG ou WebP envoyé sous uploads/{yourUserId}/. Les URL distantes ne sont pas acceptées.Longueur minimale: 1. Longueur maximale: 512.
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

Cette opération renvoie HTTP 202 pendant son exécution. Conservez requestId et interrogez action_request_get avec cet identifiant et le nom de l’opération d’origine. Les états de suivi sont running, completed, failed et interrupted. Un résultat terminé peut renvoyer vers une tâche média distincte ; poursuivez avec l’action de statut ou de résultat propre à l’opération. Métadonnées finales de génération renvoyées par le gestionnaire après la fin de la génération de l’image. Aucun octet d’image, previewDataUrl ou URL de téléchargement n’est inclus.

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

  • Exige images:write. Les espaces en début et en fin du prompt sont supprimés ; il doit contenir 10–1200 caractères et est également normalisé avant la génération. aspectRatio vaut square par défaut et accepte aussi landscape ou portrait. Au maximum un referenceImageKey est accepté.
  • Cette action est longue. La réponse API/MCP initiale indique normalement running ; interrogez action_request_get avec l’opération images_generate et le même requestId pour obtenir le résultat final présenté ici.
  • Utilise le quota quotidien habituel de génération d’images du compte. Les images générées du compte expirent sept jours après leur création ; téléchargez le résultat avant expiresAt.
  • Cette action utilise les créations et les envois de l’utilisateur connecté, y compris lorsque l’identifiant d’accès est connecté dans un contexte d’équipe.
  • Les clés de référence doivent pointer vers des envois terminés sous uploads/{yourUserId}/ et se terminer par .jpg, .jpeg, .png ou .webp. Les URL distantes, les clés d’autres utilisateurs, les segments de traversée de répertoire, les barres obliques inverses, les séquences d’échappement avec pourcentage, les chaînes de requête, les fragments et les caractères de contrôle sont refusés.
  • Chaque référence doit être non vide, ne pas dépasser 8 MiB (8,388,608 octets), pouvoir être décodée comme le type d’image indiqué par son extension et mesurer 128–4096 pixels de chaque côté. Le nombre de pixels décodés est également limité. Une référence envoyée reste réutilisable ; ces actions de génération ne consomment ni ne suppriment son fichier envoyé.
  • 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.
  • Une seule image peut être générée à la fois pour cet utilisateur. Utilisez images_list et images_get pour vérifier l’état de création, et images_download pour obtenir les octets PNG. L’identifiant de génération est une chaîne opaque ; ne le remplacez pas par requestId.

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