Asunto: El endpoint de fusión de PDF falla en Stirling-PDF (Docker) a través de n8n - Mientras que otros endpoints funcionan bien. Hola a todos,

Preguntas
1

​
​Estoy experimentando un problema persistente con el endpoint Merge PDFs en Stirling-PDF mientras uso n8n. Espero que alguien pueda aclarar la configuración correcta.
​Mi entorno:
​Implementación: Tanto n8n como Stirling-PDF se ejecutan en contenedores Docker separados en la misma máquina.
​Autenticación: SECURITY_APIKEY está habilitada en las variables de entorno de Docker de Stirling-PDF.
​Red: n8n se comunica con Stirling-PDF a través del nombre del contenedor/IP y puerto 8080.
​El problema:
​Éxito: Puedo usar exitosamente el endpoint PDF to Word. La autenticación (encabezado X-API-KEY) funciona perfectamente y el archivo se procesa.
​Fallo: Cuando intento usar el endpoint Merge PDFs (/api/v1/general/merge-pdfs), obtengo errores como 400 (Solicitud incorrecta), 401 (No autorizado) o 411 (Longitud requerida).
​Mensaje de error: A veces la respuesta indica “PDF inválido” o “Archivos faltantes”, aunque los archivos binarios se pasan correctamente desde el nodo n8n anterior.
​Detalles técnicos en n8n:
​Método: POST.
​Tipo de contenido del cuerpo: Multipart/form-data.
​Campos del cuerpo: Estoy enviando dos archivos usando el nombre de campo fileInput para ambos (según la documentación de Stirling-PDF), pero parece fallar durante el proceso de fusión.
​Mi pregunta:
Ya que la autenticación funciona para otras tareas, ¿cuál es el requisito específico para el endpoint Merge en una configuración Docker-a-Docker? ¿Espera Stirling-PDF una convención de nombres de campo diferente para múltiples archivos, o una estructura de matriz específica en la solicitud multipart?
​¡Cualquier ayuda sería muy apreciada!

3

Hola,

**Aquí está lo que realmente podría estar pasando.
**
Cuando usas fileInput para ambos archivos, el endpoint de fusión de Stirling-PDF los necesita como una estructura de array, no como nombres de campo duplicados. La mayoría de endpoints son flexibles con esto. El endpoint de fusión no lo es. Probablemente estés obteniendo un 400 porque el backend no puede analizar correctamente el array de archivos, o un 411 porque el encabezado Content-Length no se está calculando correctamente cuando n8n construye el payload multipart.

**La solución—y esta es la parte crítica.
**
En tu nodo HTTP Request de n8n, necesitas:

  1. Cambiar al modo raw body en lugar de confiar en el manejo multipart automático de n8n. Esto te da control.

  2. Construir el límite multipart manualmente o usar un nodo de librería multipart adecuado si n8n lo soporta (consulta los documentos del nodo HTTP Request para la versión más reciente).

  3. Nombres de campo: Usa files (plural) como nombre del campo, no fileInput. El endpoint de fusión de Stirling-PDF específicamente espera esto. Algunas versiones usan la sintaxis file[]—prueba ambas.

  4. Asegúrate de que Content-Length esté configurado explícitamente. El error 411 indica claramente que falta el encabezado Content-Length. n8n a veces lo elimina en la comunicación Docker-a-Docker.

El encabezado de autenticación se mantiene igual—tu X-API-KEY está bien. Pero añade Content-Type: multipart/form-data; boundary=----TuLímiteAquí explícitamente.

Detalle de redes Docker: Como estás en contenedor-a-contenedor, asegúrate de estar usando el nombre del servicio (stirling-pdf:8080 si ese es el nombre de tu contenedor) en la URL, no localhost. Probablemente ya estés haciendo esto ya que PDF to Word funciona, pero vale la pena confirmarlo.

Una cosa más—revisa los logs de Stirling-PDF directamente. Ejecuta docker logs <nombre-del-contenedor-stirling-pdf> y busca el error real del endpoint de fusión. A veces dirá “missing field: files” o “invalid multipart structure”—eso te dice exactamente qué arreglar.

¿Qué versión de Stirling-PDF estás ejecutando, y puedes compartir una captura de pantalla de cómo estás configurando actualmente el body en n8n?