Aller au contenu principal

Solution API image

Générez des images avec les contrôles que le modèle expose réellement.

Chaque point d’accès image déclare ses propres champs : invite négative ici, graine là, quatre candidats par appel ailleurs. Un formulaire générique masque précisément les contrôles qui rendent un résultat reproductible.

L’enjeu

Les formulaires génériques perdent les contrôles qui comptent

« Une invite, une image » tient une dizaine de secondes. Ensuite il vous faut le même personnage une seconde fois, du 3:2 plutôt que du carré, quatre candidats par appel et une graine que vous pouvez noter.

01

Une seed aide à comparer, sans garantir les mêmes pixels

Si le modèle accepte une seed, conservez-la avec le prompt, la version, la taille et les références. Certains endpoints peuvent produire une autre image avec la même seed.

02

La taille est un champ, pas un préréglage

Certains points d’accès prennent resolution ou aspect_ratio, d’autres width et height en pixels. Se tromper donne un 400, et là où la facturation est au mégapixel, la taille choisie est aussi le prix payé.

03

Un appel peut renvoyer plusieurs images

Là où num_outputs existe, la facturation suit le nombre d’images et non le nombre de requêtes. Une valeur par défaut de 4 coûte quatre fois celle de 1, et cet écart n’est visible avant l’envoi que dans l’estimation.

La méthode

Lire le schéma, garder les champs, journaliser la graine

Construisez les entrées selon le schéma de l’endpoint. Gardez la requête exacte, l’ordre des références et la version avec le résultat pour comparer les variantes. Conservez l’original : une reproduction identique n’est pas garantie.

Les tâches image utilisent le même contrat « créer puis suivre » que la vidéo. Toute la différence tient dans input.

POST /api/v1/jobs/createTask

POST /api/v1/jobs/createTask
Authorization: Bearer $SPICY_API_KEY
Idempotency-Key: 7b1f0c2e-9a4d-4f31-8c67-2b5e0d9a1c44
Content-Type: application/json
{
  "model": "<publisher>/<model>/text-to-image",
  "input": {
    "prompt": "A ceramic teapot on linen, soft window light, muted palette",
    "aspect_ratio": "3:2",
    "num_outputs": 2,
    "seed": 1337
  }
}

GET /api/v1/jobs/recordInfo?taskId=…

{
  "code": 200,
  "msg": "success",
  "request_id": "req_example_record",
  "data": {
    "taskId": "job_01k3m8x9q2z4v7n5p6r8s0t1w3",
    "state": "succeeded",
    "output": {
      "assets": [
        {
          "mime": "image/png",
          "url": "https://…/result.png?X-Amz-Signature=…",
          "expiresAt": "2026-09-12T12:20:08Z"
        }
      ]
    },
    "cost": "0.040000",
    "settled": true
  }
}

Contrat

Les points à figer d’emblée

API de génération d’images : plusieurs modèles — Les points à figer d’emblée
Champ ou en-têteValeur ou limite
inputadditionalProperties: false
seed · num_outputs · aspect_ratiodeclared per endpoint
cost + settled: falsehold · final charge never exceeds it
errorCode9 stable values, content_rejected included

Balayez horizontalement pour voir toutes les colonnes.

Intégration

Du premier appel à la production

  1. 01Ouvrez la page modèle et repérez lesquels de seed, negative_prompt, num_outputs et champs de taille sont déclarés.
  2. 02Construisez le corps depuis input_schema ; additionalProperties est fermé, une clé non déclarée donne un 400 et non un silence.
  3. 03Estimez, envoyez avec une clé d’idempotence, puis stockez taskId, graine et valeur model résolue à côté du résultat.
  4. 04Récupérez output.assets depuis le rappel ou recordInfo et copiez les fichiers dans votre propre stockage.

Pertinence

Quand cette voie convient

À choisir si

  • Vous générez depuis du texte et voulez plusieurs éditeurs derrière une seule forme de requête, un seul solde et une seule facture.
  • Vous souhaitez comparer des variantes avec une requête et une version de modèle enregistrées.

À éviter si

  • Vos utilisateurs partent d’une image existante. L’édition est une tâche distincte avec son propre contrat de référence.
  • Vous voulez un style maison unique sur tous les modèles. Le style vit dans le modèle, pas dans cette couche.

Vérifications

Ce que vous pouvez contrôler vous-même

La requête d’essai est la requête de production

Le corps assemblé sur la page modèle est celui que votre serveur envoie : mêmes champs, même validation, même estimation. Aucun aperçu simplifié ne divergera plus tard.

Les champs non déclarés échouent bruyamment

L’entrée est validée contre le schéma du point d’accès avec additionalProperties fermé. Un paramètre non déclaré renvoie 400 avec un errorCode stable au lieu d’être ignoré.

Les sorties viennent du stockage de la plateforme

Les résultats arrivent dans output.assets avec key, type MIME, url signée et expiresAt. Rien ne pointe vers l’endroit où le modèle a tourné.

Avant la mise en production

Comportements de la plateforme à confirmer

  • Décidez avant le lancement où sont stockées les graines ; une graine non conservée ne sert à rien.
  • Posez le plafond quotidien obligatoire sur chaque nouvelle clé, plus les plafonds mensuel et cumulé si nécessaire.
  • Traitez l’ensemble fermé d’errorCode, content_rejected compris, comme des états produit ordinaires.
  • Recopiez les fichiers dans votre stockage pendant la fenêtre de conservation de 14 jours.

Questions fréquentes

Ce qu’on nous demande sur cette page

Réutilisez les entrées, la version et la seed si disponible. Cela ne garantit pas des pixels identiques. Téléchargez et gardez le résultat original lorsque vous avez besoin de cette image précise.