Skip to main content
POST
Prepara la carga de una referencia JPG, PNG o WebP de hasta 8 MiB. Usa images_upload_sign_parts para obtener las URL PUT, carga los bytes y después llama a images_upload_complete y usa su fileKey al generar.

Autenticación y permisos

string
requerido
Envía una clave de API de VoiceCheap en esta cabecera. También se admite Authorization: Bearer con la misma clave de API. Los tokens de acceso OAuth solo se aceptan en MCP, no en este endpoint REST.
Permisos necesarios: images:write. Se requiere una suscripción de pago activa. Los permisos no cambian los roles del equipo, la propiedad de los recursos, los créditos multimedia ni los límites del plan.

Parámetros

string
Opcional en la capa de transporte: el servidor introduce un identificador antes de la validación si se omite. Proporciona tu propio UUID v4 estable para recuperar la solicitud de forma segura si se pierde la respuesta.Formato: “uuid”. Patrón: ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$.
string
requerido
El nombre de archivo de la imagen, con una extensión que coincida con contentType.Longitud mínima: 1. Longitud máxima: 250. Patrón: \.(?:jpe?g|png|webp)$.
string
requerido
Valor de texto.Valores permitidos: “image/jpeg”, “image/png”, “image/webp”.
integer
requerido
Tamaño exacto del archivo en bytes, hasta 8 MiB.Mínimo: 1. Máximo: 8388608.
El JSON Schema siguiente conserva los nombres exactos de los campos, los tipos anidados, los valores predeterminados, los límites y los valores aceptados que expone el descubrimiento. Las reglas adicionales entre campos se indican en las notas de la operación.

Idempotencia

Usa un UUID v4 en requestId o en la cabecera HTTP Idempotency-Key para cada modificación. Reutiliza el mismo identificador y argumentos idénticos después de un fallo de red. Si proporcionas ambos, deben coincidir. Repetir una solicitud guardada no vuelve a ejecutar la operación ni consume otra llamada mensual. Las solicitudes fallidas o interrumpidas no se reinician automáticamente. Toda modificación puede devolver HTTP 202 cuando un reintento encuentra la misma solicitud todavía en ejecución, incluso si su primera ejecución suele ser síncrona. Si la ejecución ha terminado pero resultStored es false, un reintento devuelve HTTP 200 con el estado de la solicitud guardada en lugar del resultado original. Recupera la salida mediante la acción de historial, resultado o descarga de su ámbito.

Ejemplos de solicitud

Sustituye los identificadores de recursos y las claves multimedia de los ejemplos por valores devueltos para tu cuenta. Mantén el identificador de solicitud al reintentar la misma modificación.

Respuesta

Una primera ejecución correcta devuelve HTTP 200 con el resultado de la operación en data. Una repetición puede devolver el estado de la solicitud guardada en su lugar. El ejemplo muestra una respuesta admitida, no todos los campos opcionales. Una nueva sesión de carga multiparte de una imagen de referencia, la futura clave del objeto, el tamaño de las partes en bytes y el número máximo de cargas paralelas. No carga ningún byte de imagen ni deja key listo para la generación.

Campos del resultado

Recuperar y consultar esta solicitud

Usa el mismo identificador incluso después de perder la conexión. Si resultStored es false, recupera la salida mediante la acción correspondiente de historial, resultado o descarga. Nunca inicies una segunda generación solo para comprobar el progreso.
HTTP 200

Notas de la operación

  • Requiere images:write; no se necesita un ámbito adicional de carga.
  • Se eliminan los espacios al principio y al final de filename, que debe contener entre 1–250 caracteres y terminar en .jpg, .jpeg, .png o .webp. Su extensión debe coincidir con contentType: image/jpeg, image/png o image/webp. fileSize es el número entero exacto de bytes, de 1 a 8,388,608.
  • La implementación compartida de carga devuelve partSize 5 MiB (5,242,880 bytes) para estas referencias. Un archivo de como máximo 5 MiB usa una parte; un archivo mayor, de hasta 8 MiB, usa dos. Solicita las URL PUT con images_upload_sign_parts, carga los bytes y después llama a images_upload_complete.
  • Usa el fileKey devuelto por la finalización como referenceImageKey en images_generate. El resultado de initialize usa key, no fileKey. No envíes key a la generación antes de la finalización.
  • La sesión de subida de producción caduca tras 24 horas. Las URL firmadas de las partes caducan tras una hora. La finalización y la anulación eliminan la sesión activa; después, sign-parts y complete devuelven Upload not found. Ninguna respuesta incluye un campo expiresAt.
  • Esta acción usa las creaciones y cargas propias del usuario conectado, también cuando la credencial está conectada en un contexto de equipo.
  • Usa un requestId UUID v4 o la cabecera HTTP Idempotency-Key, y reutilízalo con entradas idénticas al reintentar. La capa de integración registra cada modificación y devuelve su estado o resultado registrado sin volver a ejecutarla. Una solicitud fallida o interrumpida no se reintenta automáticamente.
  • El nombre de archivo de la clave del objeto se sanea y puede acortarse. Conserva la clave exacta y el uploadId devueltos; no los construyas por tu cuenta. Durante la generación se validan los bytes de la imagen, además del tamaño y el tipo declarados durante la subida.

Uso

Cada invocación correcta consume una llamada mensual de API/MCP. También se aplican los créditos multimedia y las cuotas de generación propias de la operación.

Errores