WooCommerce y Quipu con n8n: los 5 errores que te van a bloquear
Conectar WooCommerce con Quipu para que cada pedido pagado genere su factura automáticamente parece un trabajo de una tarde. Lo es, más o menos, salvo por cinco errores que no aparecen en la documentación de nadie: ni en la de n8n, ni en la de WooCommerce, ni en el OpenAPI que publica Quipu.
Este artículo recoge los cinco con el mensaje literal que devuelve cada uno, porque lo más probable es que hayas llegado aquí pegando uno de ellos en Google. Todos se reprodujeron montando el flujo completo contra la API real.
rest_no_route / 404 Not Found al llamar a la REST API de WooCommerce
Es el primero y el más desconcertante, porque las credenciales son correctas y la tienda funciona perfectamente en el navegador.
La causa no está en WooCommerce sino en WordPress: si los enlaces permanentes están configurados como «Simple», la REST API no expone sus rutas. WordPress necesita las reescrituras de URL activas para resolver /wp-json/.
La solución son dos clics:
- Ajustes → Enlaces permanentes
- Selecciona Nombre de la entrada y guarda
No hace falta tocar nada más. Guardar la página de enlaces permanentes regenera las reglas de reescritura, y la API responde inmediatamente.
401 Unauthorized aunque la clave y el secreto sean correctos
El segundo error aparece justo después de arreglar el anterior. Has generado la clave en WooCommerce → Ajustes → Avanzado → REST API con permisos de Lectura/Escritura, la has pegado en n8n, y aun así WooCommerce responde 401.
El motivo es que WooCommerce autentica por defecto mediante la cabecera Authorization, y muchos servidores la eliminan antes de que llegue a PHP. Es especialmente común en hostings compartidos y en algunas configuraciones de Apache con CGI.
En el nodo de n8n, abre la credencial de WooCommerce y activa «Include Credentials in Query». Eso envía consumer_key y consumer_secret como parámetros de la URL en lugar de en la cabecera.
Un matiz importante: enviar credenciales en la query string es menos limpio que hacerlo por cabecera y deja las claves en los logs del servidor. Úsalo solo sobre HTTPS, y si controlas el servidor, mejor arregla el paso de la cabecera Authorization en su configuración.
400 invalid_scope al pedir el token de Quipu
Aquí es donde se pierde más tiempo, porque el error parece indicar que las credenciales están mal. No lo están.
{
"error": "invalid_scope",
"error_description": "The requested scope is invalid, unknown, or malformed."
}Si tu app_id o tu app_secret fueran incorrectos, Quipu devolvería invalid_client. Que devuelva invalid_scope significa que te ha autenticado correctamente y ha rechazado la petición por otro motivo: falta el scope.
La API de Quipu define un único scope, ecommerce, y es obligatorio en toda petición de token. Si lo omites, siempre obtendrás este 400.
En n8n no necesitas construir la petición a mano. Crea una credencial genérica en Credentials → New → OAuth2 API con esta configuración:
- Grant Type:
Client Credentials - Access Token URL:
https://getquipu.com/oauth/token - Client ID: tu
app_id - Client Secret: tu
app_secret - Scope:
ecommerce - Authentication:
Send as Basic Auth header
Las claves están en Quipu, en Ajustes → Integraciones. El token caduca a las dos horas y n8n lo renueva solo.
El campo filing_number es obligatorio cuando se indica issue_date
Con la autenticación resuelta llega el siguiente muro, esta vez un 422 al crear la factura:
{
"errors": [
{
"detail": "El campo filing_number es obligatorio cuando se indica issue_date",
"source": { "pointer": "/data/attributes/filing_number" }
}
]
}La reacción natural es poner un número en filing_number y seguir. No lo hagas.
En la API de Quipu, filing_number y la relación numeration son mutuamente excluyentes. Si envías el primero, te conviertes en responsable de generar la numeración, y eso falla de dos maneras.
La primera es técnica: si dos pedidos se pagan con segundos de diferencia, ambos leen el mismo último número y ambos escriben el siguiente. Facturas duplicadas.
La segunda es más seria. En España la numeración de las facturas debe ser correlativa y sin huecos. Un flujo que puede duplicar números o dejar saltos no es un bug menor de un proyecto personal: es un problema contable para quien lo esté usando.
La solución correcta es no numerar tú y pasarle a Quipu la serie de numeración. Así la secuencia la mantiene él:
{
"data": {
"type": "invoices",
"attributes": { "kind": "income", "issue_date": "2026-08-21" },
"relationships": {
"contact": { "data": { "id": "11720845", "type": "contacts" } },
"numeration": { "data": { "id": "1100846", "type": "numbering_series" } }
}
}
}El id de tus series lo obtienes con GET /{owner_slug}/numbering_series. Un detalle que conviene tener en cuenta: la respuesta suele incluir también series rectificativas, que sirven para abonos y no para facturas de venta. Filtra por el atributo amending y quédate con una normal, o acabarás emitiendo tus ventas contra la serie equivocada.
no está incluido en la lista en payment_method
El último es el más irritante, porque contradice a la propia documentación:
{
"errors": [
{
"detail": "no está incluido en la lista",
"source": { "pointer": "/data/attributes/payment_method" }
}
]
}El OpenAPI de Quipu declara payment_method como una cadena sin restricciones. La API real lo valida contra una lista cerrada que no está publicada en ningún sitio: ni en su especificación, ni en su cliente PHP oficial, ni en su centro de ayuda.
Valores comprobados: card no es válido, bank_transfer sí lo es.
Como el campo es opcional y anulable, la respuesta más sensata es no enviarlo. La factura se crea igual. Es la lección general de esta integración: cada campo opcional que mandas «por si acaso» es una superficie más donde fallar.
Si necesitas registrar la forma de pago, la única manera fiable de averiguar el literal correcto es empírica: crea una factura a mano en Quipu eligiendo el método que uses, y luego consulta GET /{owner_slug}/invoices para leer el valor exacto en attributes.payment_method.
Extra: n8n te devuelve el cuerpo como texto y no lo parece
Este no da error, que es justo lo que lo hace peligroso. Quipu responde con un Content-Type propio, application/vnd.quipu.v1+json, y n8n no lo reconoce como JSON. En lugar de parsearlo, entrega el cuerpo como texto plano dentro de una propiedad data.
El resultado es que expresiones como $json.data.id devuelven undefined sin que nada indique por qué, y los fallos aparecen dos o tres nodos más adelante.
En cada nodo HTTP Request que llame a Quipu, entra en Options → Response → Response Format y fíjalo en JSON. Y recuerda que las cabeceras que espera Quipu son las suyas, no las genéricas de JSON:API:
Accept: application/vnd.quipu.v1+json
Content-Type: application/vnd.quipu.v1+jsonSi envías application/vnd.api+json, Quipu lo rechaza.
Dónde ejecutar el flujo
Un detalle práctico que suele quedar fuera de estas guías: el workflow tiene que estar corriendo en algún sitio para recibir los webhooks de WooCommerce. n8n en la nube funciona sin más, pero para un volumen pequeño sale bastante más barato autoalojarlo en un VPS, que es también lo que te permite quedarte por debajo de los límites de ejecuciones. Un servidor modesto sobra: estos flujos consumen prácticamente nada. Si vas por ahí, un VPS básico cubre de sobra el caso.
Una nota sobre VeriFactu
Si estás montando esto ahora, merece la pena tenerlo en cuenta desde el principio. VeriFactu será obligatorio el 1 de enero de 2027 para sociedades y el 1 de julio de 2027 para autónomos, tras el aplazamiento aprobado por el Real Decreto-ley 15/2025.
Quipu expone un endpoint /simplified_invoices compatible con VeriFactu. En el flujo es un cambio de una línea: la URL y el type del payload. Dejarlo preparado ahora cuesta menos que rehacerlo después.
Estos cinco errores son, en la práctica, toda la dificultad de la integración. El resto (leer el pedido, mapear las líneas, calcular el IVA, escribir el número de factura de vuelta en WooCommerce) es trabajo mecánico. Si los resuelves en este orden, el flujo entero se monta en una tarde.