Envío de tareas y sondeo
Todos los endpoints de envío son tareas asíncronas: tras el envío devuelven untask_id, luego se consulta periódicamente GET /v1/midjourney/{task_id} para obtener el estado, hasta SUCCESS / FAILURE.
- Ritmo de sondeo: se recomienda una vez cada 3–5 s; una frecuencia mayor no aporta nada y desperdicia cuota.
- No bloquee de forma síncrona dentro de una petición web esperando a que la tarea termine: tras el envío devuelva de inmediato el
task_idy deje que el frontend sondee de forma asíncrona.
Diseño de prompts
Un buen prompt:- El sujeto primero: primero el sujeto, luego la descripción de la escena y al final los modificadores.
- Parámetros estructurados explícitos: usar
--ar/--v/--s(o los campos del body correspondientes) es más controlable que depender de los valores por defecto. - Evite palabras ambiguas:
photorealistices más preciso querealistic.
niji: true + version: "7"; la plataforma lo normaliza a --niji 7 y la facturación va por midjourney@imagine-niji7.
Buenas prácticas de generación guiada por imagen
- Comprima a < 5 MiB: el límite de la plataforma es 12 MiB, pero las imágenes pequeñas se transmiten y procesan más rápido.
- Se aceptan los formatos PNG / JPG / WebP; se recomienda JPG de alta calidad.
- Una resolución de 1024–2048 px es suficiente; más es desperdicio.
- Peso de imagen
iw(0–3, por defecto 1): >1 se ajusta más a la imagen original, <1 da más libertad.
Manejo de errores y estrategia de reintentos
Flujo de operaciones secundarias
⚠️ Tras entrar en MODAL, inpaint debe llamar a /modal en un plazo de 30 minutos, de lo contrario el backend hace CANCEL automático + reembolso.
Control de facturación de video
- Un solo segmento:
batch_size: 1→ descuenta 1 ×midjourney@video - Lote de 4 segmentos:
batch_size: 4→ descuenta 4 ×midjourney@video - Un segmento en alta definición:
video_type: "vid_1.1_i2v_720"+batch_size: 1→ descuenta 1 ×midjourney@video-720p
batch_size=1; reserve 4 únicamente para comparar borradores en lote, no lo deje en 4 por defecto (multiplica el coste por N).
Concurrencia y rendimiento
- La plataforma impone un límite de envíos por minuto; al superarlo devuelve
429y hay que reintentar con retroceso. - La concurrencia real de generación la determina la capacidad del sistema; lo que la supere se pone en cola. Si una tarea permanece mucho tiempo en
SUBMITTED, normalmente está en cola. - El sondeo debe incluir siempre un
sleep; no haga un bucle infinito sin sleep.