FLUX 3 para desarrolladores: flujos de imagen

Si tuviera que lanzar FLUX 3 hoy, me centraría primero en tres aspectos: claves seguras, control de tareas asíncronas y almacenamiento rápido de recursos. Ese es el núcleo de esta guía. Explica cómo enviar tareas de generación y edición, cómo consultar el estado de las tareas, cómo trabajar con edición de una imagen, edición local con bbox y referencias de varias imágenes, y qué revisar antes del lanzamiento. Puedes probar FLUX 3 Image API directamente en APIMart.

Este es el resumen:

• FLUX 3 gestiona tanto generación como edición en un único flujo de imágenes.
• Las tareas son asíncronas: envío la tarea, guardo el task_id y consulto /v1/tasks/{task_id} hasta que el estado sea completed o failed.
• APIMart conserva los resultados generados durante 72 horas.
• Las reglas de reintento importan: reintenta 429 y 5xx con espera; corrige 400, 401 y 402 antes de volver a probar.
• La resolución determina la espera y el coste: 4k puede tardar varios minutos, y la documentación recomienda un tiempo de espera total de 10 minutos.
• Envía las imágenes de origen como URL públicas en image_urls. Base64 también funciona, pero añade alrededor de un 33 % de carga.
• Según los precios de tarifa de octubre de 2026, FLUX 3 Image cuesta 0,048 USD por imagen en 1k y 0,607 USD en 4k: aproximadamente 12,6 veces más. FLUX 3 Image
• Antes del lanzamiento revisaría colas, límites de frecuencia, registros, seguridad y seguimiento del gasto en USD.

La conclusión principal es que FLUX 3 no consiste tanto en una sola llamada a la API como en crear una canalización limpia para tareas, archivos, reintentos y costes.

Comparación rápida

Este artículo se centra en lo necesario para lanzar: flujo de solicitudes, control de edición, configuración de producción y puntos de vigilancia de costes, no solo en resultados de demostración.

Puntos clave

• FLUX 3 Image gestiona texto a imagen, edición de una imagen, referencias de varias imágenes (hasta 10) y edición local con bbox escrita en el prompt mediante un único endpoint asíncrono. No tiene parámetro mask ni parámetro de intensidad (strength).
• Las tareas siguen el flujo «POST devuelve task_id»: consulta /v1/tasks/{task_id} y detente cuando el estado sea completed o failed. 4k puede tardar varios minutos y la documentación recomienda un tiempo de espera total de 10 minutos.
• Reintenta las respuestas 429 y 5xx con backoff exponencial, corrige los errores 400, 401 y 402 antes de reintentar y persiste el task_id para que los reintentos no creen trabajos facturables duplicados.
• APIMart conserva los resultados generados durante 72 horas.
• Según los precios de tarifa de octubre de 2026, FLUX 3 Image cuesta 0,048 USD por imagen en 1k y 0,607 USD en 4k: aproximadamente 12,6 veces más. Una sola clave API de APIMart permite llamar a modelos de varios proveedores.

FLUX 3 de un vistazo

Resumen en vídeo de los flujos de FLUX 3

Flujos de FLUX 3: autenticación, solicitudes y tareas

Las integraciones estables de FLUX 3 dependen de tres elementos: claves seguras, URL temporales de imágenes y gestión de tareas asíncronas.

Configurar claves de API y una configuración segura

Nunca escribas claves directamente en el código fuente. Guárdalas en el servidor mediante un gestor de secretos y no las expongas en código cliente ni repositorios públicos. Si se filtra una clave, rótala inmediatamente desde el panel de APIMart.

Conviene tratar la rotación como mantenimiento periódico, no como una emergencia. Esta mentalidad mantiene ordenada la configuración y reduce el riesgo antes de que se convierta en un problema.

Las credenciales seguras, el tratamiento predecible de solicitudes y la gestión fiable de tareas son la base para lanzar funciones de imagen capaces de operar en producción.

Crear solicitudes prompt-to-image y gestionar respuestas

Una solicitud básica de generación FLUX 3 necesita:

• un ID de modelo
• un prompt de texto
• un tamaño o relación de aspecto

APIMart conserva los resultados generados durante 72 horas. Descarga las imágenes en cuanto termine la tarea y guárdalas en tu propio almacenamiento, como S3, si necesitas conservarlas a largo plazo.

Gestionar consultas, reintentos y errores en tareas largas

La generación de imágenes es asíncrona. Una solicitud POST envía la tarea y devuelve un task_id. Después, consulta GET /v1/tasks/{task_id} y detente cuando el estado sea completed o failed. La documentación no fija un intervalo de consulta, así que empieza con unos segundos y alárgalo progresivamente.

Fija el límite de espera según la resolución. 4k puede tardar varios minutos y la documentación recomienda un tiempo de espera total de 10 minutos; para resoluciones más bajas basta un límite menor. Alcanzar ese límite solo significa que tu cliente deja de esperar. No significa que la tarea haya fallado, algo que solo ocurre cuando el estado devuelve failed. Conserva el task_id para volver a consultarlo más tarde en lugar de enviar una tarea duplicada.

Los reintentos requieren criterio. No todos los errores deben recibir el mismo tratamiento.

• Las respuestas 429 y 5xx deben activar una espera exponencial y un reintento.
• Los errores 400, 401 y 402 indican un problema de la solicitud, como parámetros incorrectos, una clave ausente o no válida o saldo insuficiente.

Si la solicitud está mal, reintentar sin corregir la causa solo malgasta créditos y tiempo. Además, guarda el task_id antes de repetir para no crear tareas facturables duplicadas.

Estas reglas de reintento se aplican igual a texto a imagen, edición de una imagen o edición local.

Los flujos se diferencian sobre todo en el contenido de la solicitud. Todos usan el mismo endpoint y modelo, y se facturan según resolution.

La documentación del modelo no ofrece webhook ni callback_url, así que en producción tienes que gestionar el sondeo tú mismo: controla la concurrencia con una cola y registra el estado de cada task_id.

Con el manejo de solicitudes estable, el siguiente paso es decidir cómo entregar al modelo las imágenes de origen y las instrucciones de edición.

Flujos de edición de imágenes con FLUX 3: edición de una imagen, edición local y referencias de varias imágenes

Con el envío de tareas y los reintentos listos, la siguiente decisión es sencilla: ¿cuánto de la imagen de origen debe mantenerse y cuánto debe cambiar? Todas las ediciones de FLUX 3 Image pasan por image_urls más el prompt, con tres patrones principales: edición de una imagen, edición local con bbox y referencias de varias imágenes.

Edición de una imagen para cambios visuales controlados

Envía una imagen de origen en image_urls e indica en el prompt qué debe cambiar y qué debe mantenerse. El modelo no tiene un parámetro de intensidad tipo strength, así que el prompt es la única forma de controlar cuánto cambia la imagen. Con aspect_ratio en auto, la salida sigue la relación de aspecto de la primera imagen de referencia.

Funciona bien para variantes de producto, renovación de anuncios y cambios de estilo de marca. Especifica claramente qué no debe cambiar. Si lo dejas ambiguo, el modelo puede alejarse del origen. Un caso práctico es reutilizar la misma foto para variantes estacionales en lugar de organizar otra sesión.

Las imágenes de origen pueden ser URL HTTP(S) públicas o Base64. Base64 añade alrededor de un 33 % de carga, así que una URL pública, por ejemplo de una CDN, suele ser la mejor opción.

Delimita la edición local con bbox

El modelo no tiene parámetro mask, y enviar mask_url devuelve HTTP 400. Para cambiar solo una zona, nombra los elementos en el prompt con etiquetas como <car_1> y añade un array JSON de bbox al final de la misma cadena. Las cajas usan [top, left, bottom, right] sobre una cuadrícula normalizada de 0 a 1000, no píxeles. Si tgt_bbox es igual a src_bbox, el elemento se queda en su sitio; una caja distinta lo mueve. Este ejemplo pinta de rojo el coche marcado y conserva el fondo:

{
  "model": "flux-3-image",
  "prompt": "In <ref_image_0>, make the car <car_1> red and preserve the background <background_1>. [{\"id\":\"car_1\",\"from\":null,\"src_bbox\":null,\"tgt_bbox\":[250,300,750,800],\"desc\":\"A red car, preserving its original shape and orientation.\"},{\"id\":\"background_1\",\"from\":\"ref_image_0\",\"src_bbox\":[0,0,1000,1000],\"tgt_bbox\":[0,0,1000,1000],\"desc\":\"Preserve the original road, background, and lighting.\"}]",
  "image_urls": [
    "https://example.com/car.jpg"
  ],
  "aspect_ratio": "auto",
  "resolution": "2k"
}

No existe un parámetro específico de outpainting. En las referencias de varias imágenes, las imágenes se numeran en orden como ref_image_0, ref_image_1, etc., y en el prompt también puedes escribir Image 1 / Image 2, por ejemplo «Turn Image 1 into the style of Image 2.»

Usa resolution: "768sq" para las vistas previas y elige 1k, 1.5k, 2k o 4k para la entrega. Son niveles de resolución, no dimensiones width/height en píxeles: 4k equivale a unos 16 MP y 2k a unos 4 MP. FLUX 3 Image

Encadenar ediciones en canalizaciones repetibles

Una estructura sencilla es:

• Usa la edición de una imagen para ajustar estilo o detalles
• Usa la edición local con bbox para cambiar o mover elementos concretos
• Usa la referencia de varias imágenes para combinar sujetos y estilos
• Guardar cada etapa como recurso intermedio

Antes de subir, evita las exportaciones desde canvas del navegador y cualquier recompresión adicional para no perder detalle. Envía el archivo original directamente.

Cuando las ediciones sean estables, el siguiente reto es convertirlas en un único flujo de producto con control de acceso y costes.

Utilizar FLUX 3 mediante APIMart para integrar y controlar costes

Cuando las ediciones sean repetibles, APIMart puede actuar como capa central de control en producción. En lugar de conectar por separado cada parte, dirige la canalización a través de una capa de API que gestione acceso, gasto y automatización posterior.

Conectar FLUX 3 con un flujo de API unificado

Si ya utilizas clientes al estilo OpenAI, la configuración suele ser ligera. Normalmente solo hay que cambiar la URL base, añadir la clave y dirigir las solicitudes al ID de FLUX 3.

Puedes mantener la estructura de solicitudes, el análisis, las reglas de reintento y la lógica asíncrona. Las tareas FLUX 3 siguen en APIMart el mismo flujo de POST a task_id y posterior consulta mediante GET, por lo que el código existente funciona tanto para una generación como para varias ediciones encadenadas. Una clave de APIMart también puede cubrir varios modelos y proyectos.

Controlar uso, presupuestos y cargas del equipo en USD

El panel de APIMart reúne el uso de modelos y proyectos y muestra los costes en USD. Así resulta más fácil decidir qué flujos están listos para producción y cuáles aún necesitan ajustes.

Por ejemplo, puedes establecer un límite mensual para un proyecto de catálogo y una alerta antes de alcanzarlo. El equipo tendrá margen para reducir o pausar lotes antes de que el coste se descontrole.

Según los precios de tarifa de octubre de 2026, FLUX 3 Image cuesta 0,048 USD por imagen en 1k y 0,607 USD en 4k: aproximadamente 12,6 veces más. Estos son los precios de tarifa de octubre de 2026, en USD por imagen. Las referencias no tienen coste adicional. Consulta la tabla de precios de FLUX 3 Image para conocer las tarifas vigentes.

Combinar FLUX 3 con flujos multimodales más amplios

Integra FLUX 3 como etapa de generación de imágenes en una canalización que también incluya redacción, análisis visual o etiquetado. Una sola clave API de APIMart permite acceder a modelos de varios proveedores. APIMart

También puedes establecer permisos por rol para que el acceso a análisis quede en manos de quien lo necesita y la gestión de claves se limite a ingenieros autorizados.

Esta configuración convierte escalado, límites y registros en la siguiente capa de las operaciones diarias.

Despliegue en producción: escalado, observabilidad y lanzamiento

Planificar colas, concurrencia y límites

Cuando la generación y la edición son estables, producción plantea otro reto. Ya no se trata de hacer funcionar una solicitud, sino de gestionar tráfico sin que el sistema falle.

La demanda puede aumentar de golpe. Por eso no conviene procesar todas las solicitudes en línea. Una cola ofrece margen: separa la recepción de la ejecución y evita que un pico golpee a todos los workers a la vez.

También hay que adaptar la concurrencia a los límites. Una forma sencilla es combinar colas con topes por modelo. Así se absorben picos sin superar las restricciones del proveedor.

Registrar los datos adecuados para depuración y reproducibilidad

Si los resultados cambian entre ejecuciones, depurar se complica rápidamente sin los campos correctos.

Para reproducir y solucionar problemas, registra el ID de solicitud, ID de tarea, prompt y metadatos de generación. Es suficiente para rastrear lo ocurrido y repetir tareas si hace falta. La profundidad del registro debe ajustarse al entorno. Los registros de staging y producción deben seguir siendo útiles sin exponer más datos de los necesarios.

También conviene registrar resolución y coste estimado por tarea. Facilita detectar valores atípicos caros antes de recibir una sorpresa en la factura.

Conclusión: cómo evaluar FLUX 3 antes de lanzar funciones de imagen

Antes de pasar FLUX 3 a producción, valida la configuración en los entornos siguientes con diferentes reglas de acceso, registro y revisión.

Utiliza esta matriz para comprobar la preparación.

Planifica la fiabilidad con pruebas de carga, monitorización y procedimientos de recuperación propios. Antes del lanzamiento, revisa los picos de tráfico, los ID de solicitud y tarea en los registros, los límites de uso, los controles de seguridad y los costes por resolución.

Si estos controles superan las pruebas de carga, FLUX 3 está listo para producción.

Para una visión completa del modelo, consulta FLUX 3: modelos, disponibilidad y precios.

Preguntas frecuentes

¿Durante cuánto tiempo debo consultar una tarea de FLUX 3?

Consulta GET /v1/tasks/{task_id} hasta que el estado sea completed o failed. La documentación del modelo no ofrece webhook ni callback_url, así que el sondeo es la forma de obtener los resultados.

Fija el límite de espera según la resolución: 4k puede tardar varios minutos y la documentación recomienda un tiempo de espera total de 10 minutos. Al llegar al límite, tu cliente deja de esperar, pero la tarea no ha fallado necesariamente. Conserva el task_id para volver a consultarla más tarde.

¿Cómo almacenar imágenes FLUX 3 en producción?

APIMart conserva los resultados generados durante 72 horas. Descarga las imágenes en cuanto termine la tarea y guárdalas en tu propio almacenamiento, como S3, si necesitas conservarlas a largo plazo.

Utiliza un flujo asíncrono. Consulta el task_id hasta completar la tarea y guarda el archivo en tu infraestructura permanente. También ayuda mantener un registro de base de datos con task_id, marcas de tiempo y ruta interna para disponer de una auditoría clara.

¿Cuál es el mejor flujo FLUX 3 para editar?

Utiliza un flujo que comience con una imagen existente y aplique un prompt específico para cambiar únicamente lo necesario. También puedes incluir texto en otros idiomas manteniendo intacto el resto del diseño.

En producción, configúralo como canalización asíncrona. Envía un POST para iniciar la edición, recibe un task_id y consulta la tarea hasta que esté completed o failed. Cuando se devuelva la URL final, guárdala antes de que caduque.

Hay algunas reglas fundamentales:

• Mantén las claves solo en el backend
• Valida las entradas antes de enviar
• APIMart conserva los resultados generados durante 72 horas.

Esta configuración mantiene limpio el flujo y evita errores innecesarios cuando aumenta el tráfico.