Skip to main content
Referencia de API para recraft/recraftv4_styles_pro_vector, servida por Comfy Router desde Recraft. Entrada: Texto · Salida: Imagen

Inicio rápido

Crea una clave en tu espacio de trabajo de Comfy y expórtala como COMFY_API_KEY. Los fragmentos de Python y TypeScript usan los SDK de Comfy (pip install comfy-sdk y npm install @comfyorg/sdk); el fragmento de cURL es la misma llamada sobre HTTP sin procesar. ID del modelo: recraft/recraftv4_styles_pro_vector Endpoint: POST https://api.comfy.org/v2/models/recraft/recraftv4_styles_pro_vector
Si envías el mismo cuerpo a POST https://api.comfy.org/v2/models/recraft/recraftv4_styles_pro_vector/requests, Router responde 201 con un request_id en cuanto admite la ejecución, y puedes recoger el resultado en cuanto esté listo, desde este proceso o desde otro. Entrega en cola explica el estado, la cancelación y la recogida.

Esquema

Entrada

object
Los controles de la imagen generada
integer
Define el tono artístico de tu imagen. En un nivel simple, la persona mira directamente a la cámara en un estilo estático y limpio. Los niveles dinámico y excéntrico introducen movimiento y creatividad.Rango: 0 a 5
object
Valores de color RGB
integer[]
requerido
object[]
Un arreglo de colores preferidos
integer[]
requerido
boolean
No incrustar diseños de texto
string
El modelo a usar para la generación (p. ej., “recraftv3”). Este campo NO está restringido a un enum: el proxy reenvía lo que envíe quien llama. Las grafías que Comfy distribuye, el conjunto que Comfy Router direcciona como recraft/<model>, son recraftv2, recraftv3, recraftv4, recraftv4_pro, recraftv4_1, recraftv4_1_utility, recraftv4_1_pro, recraftv4_1_utility_pro, recraftv4_styles, recraftv4_styles_pro, recraftv4_1_vector, recraftv4_1_utility_vector, recraftv4_1_pro_vector, recraftv4_1_utility_pro_vector, recraftv4_styles_vector y recraftv4_styles_pro_vector. Se escriben aquí en lugar de nombrarlas por referencia porque el componente RecraftGenerationModel que las declara no tiene ninguna referencia $ref y, por eso, se poda de la especificación que se sirve en GET /openapi; por lo tanto, un puntero a él quedaría apuntando a nada en el documento servido. Las cuatro grafías de recraftv4_styles* además requieren style_id: consulta ese campo.
integer
El número de imágenes a generar. Recraft acepta de 1 a 6.Rango: 1 a 6
string
requerido
El prompt de texto que describe la imagen a generar
string
Valores posibles: url, b64_json
string
El tamaño de la imagen generada (p. ej., “1024x1024”)
string
El estilo que se aplicará a la imagen generada (p. ej., “digital_illustration”)
string
El ID de estilo que se aplicará a la imagen generada (p. ej., “123e4567-e89b-12d3-a456-426614174000”). Si proporcionas style_id, no debes proporcionar style. Los cuatro modelos recraftv4_styles* lo REQUIEREN: Recraft rechaza esos modelos sin un style_id o una referencia de estilo. Crea uno con POST /proxy/recraft/styles, que este mismo proxy sirve con las mismas credenciales. Nada en esta ruta obliga a esa combinación: el cuerpo se reenvía a Recraft sin cambios, así que una llamada a recraftv4_styles* sin él llega al socio y devuelve un 4xx.
Generado a partir del esquema que Router sirve en GET /v2/models/recraft/recraftv4_styles_pro_vector/openapi.json, el mismo documento contra el que valida una llamada antes de que la solicitud llegue al proveedor.

Salida

integer
requerido
Marca de tiempo Unix de cuándo se creó la generación
integer
requerido
Número de créditos usados para la generación
object[]
requerido
Arreglo de información de las imágenes generadas
string
Datos de imagen codificados en Base64 (presentes en lugar de url cuando la solicitud estableció response_format: b64_json)
string
Identificador único de la imagen generada
string
URL para acceder a la imagen generada (presente cuando response_format es url, el valor predeterminado)
string
El ID de estilo resuelto, que devuelve Recraft cuando se usan referencias de estilo (en particular, los modelos recraftv4_styles*, que requieren entradas); se puede reutilizar como style_id en solicitudes posteriores.

Ejemplos

Entrada

Salida

Antes de lanzar

Los SDK crean una Idempotency-Key y la reutilizan para los reintentos automáticos. Para los reintentos manuales, reutiliza la clave original. Router puede mantener la conexión abierta hasta 10 minutos. Cuando una solicitud falla, Router envía un encabezado de respuesta X-Comfy-Error-Type que explica el motivo. Un 422 significa que Router rechazó la entrada antes de llamar al proveedor, y un 413 significa que el cuerpo de la solicitud era más grande de lo que Router acepta. Descarga los recursos generados de inmediato, porque las URL de resultados pueden caducar. Cualquier límite de tamaño mencionado en la descripción de un campo más arriba es el límite propio del proveedor para ese campo, citado de la especificación del proveedor. Router aplica un tope aparte al cuerpo completo de la solicitud, con el que cuentan los medios codificados en base64: consulta tamaño del cuerpo de la solicitud. Esta página documenta un modelo socio al que se llama a través de Comfy Router. El mismo paquete comfy-sdk / @comfyorg/sdk también incluye un segundo cliente, para ejecutar todo un gráfico de flujo de trabajo de ComfyUI en Comfy Cloud: Comfy(api_key=...) / new Comfy({ apiKey }), con client.workflows, client.assets y client.jobs. Consulta SDK de Comfy.

Encabezados

Autenticación, idempotencia, IDs de solicitud, agrupaciones de errores, ritmo de reintentos y límites de gasto.

Uso de la API de Router

Descubrimiento de modelos, errores de validación, reintentos y facturación.

Limitaciones

Lo que Router no hace hoy y qué usar en su lugar.