Submissão de tarefas e polling
Todos os endpoints de submissão são tarefas assíncronas: após a submissão, retornam umtask_id, e então você consulta periodicamente GET /v1/midjourney/{task_id} para obter o status, até SUCCESS / FAILURE.
- Ritmo do polling: recomendamos a cada 3–5s; frequências maiores não têm sentido e desperdiçam cota.
- Não bloqueie de forma síncrona dentro de uma requisição web esperando a tarefa terminar —— retorne o
task_idimediatamente após a submissão e deixe o frontend fazer polling assíncrono.
Design de prompt
Um bom prompt:- Sujeito primeiro: primeiro o sujeito, depois a descrição da cena e por último os modificadores.
- Parâmetros estruturados explícitos: usar
--ar/--v/--s(ou os campos correspondentes no body) é mais controlável do que depender dos valores padrão. - Evite palavras ambíguas:
photorealisticé mais claro do querealistic.
niji: true + version: "7", a plataforma normaliza para --niji 7, e a cobrança vai por midjourney@imagine-niji7.
Melhores práticas para imagem de referência
- Comprima para < 5 MiB: o limite da plataforma é 12 MiB, mas imagens menores são mais rápidas de transmitir / processar.
- Os formatos PNG / JPG / WebP são aceitos; recomendamos JPG de alta qualidade.
- Resolução de 1024–2048 px já é suficiente; mais que isso é desperdício.
- Peso da imagem de referência
iw(0–3, padrão 1): >1 fica mais próximo da imagem original, <1 fica mais livre.
Tratamento de erros e estratégia de retry
Fluxo de operações secundárias
⚠️ Depois que o inpaint entra em MODAL, é obrigatório chamar /modal dentro de 30 minutos, caso contrário o backend faz CANCEL automático + reembolso.
Controle de cobrança de video
- Trecho único:
batch_size: 1→ cobra 1 ×midjourney@video - Lote de 4 trechos:
batch_size: 4→ cobra 4 ×midjourney@video - Trecho único em HD:
video_type: "vid_1.1_i2v_720"+batch_size: 1→ cobra 1 ×midjourney@video-720p
batch_size=1; só use 4 para comparar variações em lote. Não deixe 4 como padrão (o custo multiplica por N).
Concorrência e throughput
- A plataforma tem um limite de submissões por minuto; ao exceder, retorna
429e é necessário retry com backoff. - A concorrência real de geração é determinada pela capacidade do sistema; ao exceder, entra em fila; uma tarefa parada por muito tempo em
SUBMITTEDgeralmente significa que está na fila. - O polling deve sempre incluir
sleep; não faça loop infinito sem sleep.