Midjourney no tiene una API pública general, y eso define la estructura real del «relay» y del «proxy»: no se trata de cambiar el dominio de una interfaz oficial, sino de añadir una capa de orquestación de tareas y facturación sobre grupos de cuentas de terceros. La cadena es más larga que la de una API de texto y hay más puntos donde fallar.

Este artículo parte de la cadena real y explica los estados de tarea, la retención de resultados, la conciliación de cobros, los riesgos de claves y cuentas, las condiciones del proveedor, la migración y la aceptación.

Aviso de marcas: Midjourney es una marca de Midjourney, Inc.; los demás nombres de productos son marcas de sus titulares. Este artículo solo ofrece una explicación técnica y no implica afiliación ni relación de cooperación con Midjourney; las interfaces, los estados y la facturación del servicio de relay se rigen por la documentación y el contrato del proveedor. No constituye asesoramiento legal.

1. Primero, distingue cuatro tipos de «relay»

Tipo Qué hace Riesgo principal Escenario adecuado
Proxy con grupo de cuentas El proveedor mantiene cuentas de Midjourney y envía por automatización Control de riesgo de cuentas, colas, condiciones Equipos pequeños que necesitan forma de API
Pasarela agregadora Entrada unificada con varios modelos de imagen Mapeo de estados, diferencias de parámetros, fallos de capa intermedia Negocio multimodelo
Reventa o recarga Revende suscripciones o créditos Estabilidad upstream, saldo y reembolsos Pruebas pequeñas, necesidades temporales
Automatización propia Mantienes cuentas y scripts de envío Operación, bloqueos, toda la responsabilidad Equipos técnicos que quieren control de datos

Lo que compras —«servicio técnico» o «créditos de modelo»— determina quién responde cuando algo falla. Pregunta por el contrato, la factura y las condiciones de datos según esa distinción.

2. Qué etapas añade una tarea asíncrona en el relay

Una cadena típica es así: tu servicio envía la solicitud; el relay autentica, limita la tasa y cobra; el relay persiste la tarea y crea el mapeo entre el número de pedido y el ID de tarea upstream; el grupo de cuentas hace cola para enviar y espera la generación; el relay consulta o recibe el resultado y mapea el estado; por último, almacena la imagen o reenvía un enlace temporal.

Cada salto añade un lugar donde se puede perder el estado:

  • El relay se reinicia o cambia de instancia y se pierde el mapeo de tareas en memoria.
  • El upstream no responde a tiempo, pero la tarea ya se creó; el relay devuelve fallo y el llamador reintenta, con lo que se generan dos imágenes.
  • Un rechazo por moderación se mapea como fallo genérico y el negocio reintenta una y otra vez.
  • El enlace de resultado vence; la tarea figura como exitosa pero la descarga falla.
  • El webhook no tiene clave de idempotencia y el negocio duplica el registro.

Al evaluar un relay, no preguntes solo «¿admiten Midjourney?». Pregunta cómo se persisten los ID de tarea, cómo se mapean los estados y cómo se compensan los fallos.

3. Estados de tarea y retención de resultados

Los estados habituales son en cola, generando, éxito, fallo, rechazo por moderación, timeout o vencido. El nombre no importa; lo que importa es el mapeo: el negocio debe poder distinguir «se puede reintentar» de «reintentar no sirve de nada».

Un rechazo por moderación, un error de parámetros y un saldo insuficiente no deberían reintentarse automáticamente; un timeout y un 5xx sí admiten reintento con backoff; un éxito cuya descarga falla requiere una compensación aparte. Cada tarea debe tener una clave de idempotencia para evitar cobros duplicados e imágenes duplicadas.

Sobre la retención de resultados hay cuatro preguntas: cuánto tiempo se guardan los registros de tarea; si se almacenan las imágenes en tu nombre y dónde; si se devuelve un enlace temporal o una dirección de largo plazo; y si después del vencimiento todavía puedes consultar por número de pedido. Los enlaces de imagen suelen caducar, así que conviene descargar y almacenar en cuanto la tarea tiene éxito.

4. Cómo verificar la transparencia de la facturación

La facturación de tareas de imagen genera más disputas, porque una solicitud puede incluir imagine, ampliación, variaciones y reintentos. Antes de firmar, confirma:

  • Si la unidad de cobro es la tarea, la imagen exitosa o el crédito de suscripción prorrateado.
  • Si la ampliación y las variaciones se cobran aparte.
  • Si el fallo, el timeout, la cancelación y el rechazo por moderación se cobran en cada caso.
  • Si el envío duplicado y el reintento generan doble cobro, y si hay deduplicación idempotente.
  • Si hay consumo mínimo, umbral de prepago, reglas de reembolso y tipo de factura.
  • Si el detalle de uso incluye ID de tarea, tipo de acción, estado e importe cobrado.

No mires solo el descuento de la página promocional. Ejecuta de veinte a cincuenta tareas reales durante una semana y concilia el número de imágenes exitosas, el de tareas y la factura. Si aparece una diferencia, pide el detalle de cargos por ID de tarea, no solo el total. El costo de otros modelos del sitio se rige por los precios de modelos; los precios se ajustan con el upstream.

5. Claves, cuentas y riesgo upstream

Un relay implica que los prompts, las imágenes de referencia y las imágenes finales pasan por un tercero. Como mínimo, confirma:

  • Si los prompts y las imágenes se guardan en disco, cuánto tiempo y si se usan para entrenamiento o mejora del servicio.
  • Si la clave puede limitar cuota, IP y vencimiento, y cómo se revoca tras una filtración.
  • Si el upstream es un solo grupo de cuentas o varios canales, y cómo se cambia cuando una cuenta se bloquea.
  • Si las condiciones permiten el acceso automatizado y la reventa, y cómo se reparte la responsabilidad.
  • Quién gestiona la apelación y el reembolso en una disputa de moderación de contenido.

Las claves de producción no deben estar en el frontend, en repositorios públicos ni en registros. Para material muy sensible, prioriza proveedores que permitan no persistir datos y firmar un acuerdo de tratamiento; si no puedes confirmarlo, anonimiza antes de subir.

6. Condiciones del proveedor y límites de responsabilidad

Un relay puede vender «servicio técnico» o «créditos de modelo», y las responsabilidades difieren. El proveedor de servicio técnico debería responder por disponibilidad, pérdida de tareas y plazos de respuesta; el revendedor de créditos a menudo solo puede prometer «reenvío con la mejor intención», y cuando el upstream cambia resulta difícil remediarlo.

En el contrato conviene especificar: niveles de servicio y notificación de incidentes, compensación por tareas fallidas, aviso previo ante cambios de reglas upstream, obligaciones de tratamiento y eliminación de datos, y exportación de datos y saldo al terminar la relación. No aceptes una cooperación de largo plazo que solo tenga historial de chat y ninguna entidad contractual.

7. Pasos para migrar de la conexión directa o la solución propia a un relay

  1. Inventaria las llamadas actuales: modelos, parámetros, concurrencia, tiempo medio de generación y tipos de fallo.
  2. Confirma las rutas de interfaz, el método de autenticación y las diferencias de campos del relay; prepara una tabla de mapeo.
  3. En el entorno de prueba, valida las cuatro rutas: envío, consulta, cancelación y descarga.
  4. Ejecuta una prueba en espejo con el mismo lote de prompts: la cadena original y el relay en paralelo, solo comparación, sin cambiar el tráfico.
  5. Compara tasa de éxito, tiempo en cola, latencia P95, tasa de descarga de imágenes y costo por pieza usable.
  6. Despliega de forma gradual entre 5% y 20% del tráfico, con un interruptor de reversión a la cadena original.
  7. Observa de tres a siete días y confirma que la factura, el detalle de tareas y el número de pedido cuadran.
  8. Tras completar el traspaso, mantén un tiempo el doble canal de respaldo; simplifica la arquitectura cuando esté estable.

Durante la migración, no borres las cuentas originales ni las claves antiguas, y no escribas las dos series de tareas bajo el mismo número de pedido, o la conciliación será imposible.

8. Cómo validar un relay

# Envía una tarea mínima y registra task_id y la hora de envío; rutas y campos según la documentación del proveedor
curl -sS -X POST "$RELAY_BASE_URL/v1/images/generations" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"un gato bostezando junto a la ventana, luz natural","async":true}'

# Consulta el estado y registra el flujo completo
curl -sS "$RELAY_BASE_URL/v1/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Durante la prueba, provoca anomalías: cancela justo después del envío, envía parámetros incorrectos, haz envíos concurrentes e interrumpe una descarga. Observa si el estado, el mensaje de error y la factura coinciden. Después, accede a la dirección del resultado a las veinticuatro horas y consulta el registro de la tarea a los siete días. Solo si supera estas tres pruebas vale la pena un despliegue gradual.

9. Monitoreo y reversión después de migrar

  • Cuenta las tareas por estado y revisa sobre todo la proporción de fallos, rechazos por moderación, timeouts y cancelaciones.
  • Registra por separado el tiempo en cola y el de generación para localizar si el cuello de botella está en el grupo de cuentas o en el upstream.
  • Monitorea la tasa de descarga de imágenes y envía las tareas fallidas a una cola de compensación.
  • Contabiliza 401, 404, 429 y 5xx, y distingue clave, parámetros, límite de tasa y fallo upstream.
  • Calcula el costo «por tarea de imagen exitosa», no solo el precio por llamada.
  • Define umbrales de reversión; por ejemplo, si durante dos horas seguidas la tasa de éxito cae claramente por debajo de la línea base, vuelve a la cadena original.

Preguntas frecuentes

¿Qué diferencia hay entre un relay y suscribirse directamente a Midjourney?

La suscripción directa es el producto oficial, pensado para operación manual; el relay es un encapsulamiento en forma de API, cómodo para automatizar. Pueden diferir en parámetros, concurrencia y visibilidad de tareas, y el relay asume además el riesgo del grupo de cuentas y de las condiciones.

¿El relay guarda mis prompts e imágenes?

Depende del servicio. Pregunta si se persisten, cuánto tiempo, dónde, quién puede acceder, si se usan para entrenamiento y cómo funciona la eliminación. Cuando haya material de clientes, prioriza proveedores con condiciones claras.

¿Qué hago si una tarea se pierde en el relay?

Primero busca el registro local por número de pedido; después revisa los logs del relay y la tarea upstream. Si no se puede recuperar, solo queda reenviar, así que antes de migrar confirma si el relay persiste el mapeo de tareas.

¿Por qué la factura no coincide con el número de imágenes?

Las causas habituales son envíos duplicados, reintentos de fallos, cobro separado de ampliaciones y variaciones, reglas distintas para rechazos por moderación, consumo mínimo o saldo vencido. Pide el detalle por ID de tarea y revísalo línea por línea.

¿La migración requiere cambiar código?

Si el relay es compatible con la interfaz existente, normalmente basta cambiar la URL base, la clave y algunos campos; si el mapeo de estados o el formato de callback difieren, habrá que ajustar la consulta y el registro en base de datos. Haz primero una prueba en espejo: la mayoría de las diferencias se detectan antes.

Siguiente paso

Primero crea una clave de prueba en ZSQH AI Gateway, valida con una tarea mínima las cuatro rutas —envío, consulta, descarga y conciliación— y después migra de forma gradual; los modelos disponibles y los costos se rigen por los precios de modelos, y los precios pueden cambiar.

Lecturas relacionadas: