Package Information
Documentation
n8n-nodes-invoka
Nodos de comunidad de n8n para Invoka, la API de facturación electrónica del SRI de Ecuador para programadores.
- Invoka: emite facturas, notas de crédito y débito, guías de remisión, liquidaciones de compra y retenciones 2.0 (la 1.0 queda como obsoleta). También consulta su estado, descarga el XML y el PDF, reprocesa, consulta RUC y cédulas, revisa los créditos y administra empresas y el webhook.
- Invoka Trigger: arranca un flujo cuando Invoka avisa de que un comprobante quedó autorizado o con error. Verifica la firma HMAC de cada aviso.
Documentación de la API: https://invoka.com.ec/docs
Instalación
En n8n: Settings → Community Nodes → Install y escriba n8n-nodes-invoka.
Si n8n corre por su cuenta (self-hosted):
cd ~/.n8n/nodes
npm install n8n-nodes-invoka
# reinicie n8n
Credencial
| Campo | Valor |
|---|---|
| API Key | La de su cuenta, en el panel de Invoka → Perfil. Viaja en la cabecera X-API-KEY. |
| URL de Invoka | https://invoka.com.ec. Normalmente no hay que cambiarla. |
La prueba de la credencial consulta el saldo (GET /api/creditos/saldo). No usa /api/ping porque ese endpoint no valida la clave.
Hay una sola API key por cuenta, y con ella se emite para todas las empresas (RUC) que la cuenta tenga registradas.
Ambiente: Pruebas o Producción
El ambiente se elige en cada comprobante. No va en la credencial.
- Pruebas (valor por defecto): es gratis e ilimitado. El SRI procesa el comprobante en su ambiente de pruebas y no tiene validez tributaria.
- Producción: consume 1 crédito por cada comprobante autorizado y es real ante el SRI. Cuando se elige, el nodo muestra un aviso ⚠.
El nodo siempre manda el ambiente que diga ese campo, aunque se use el modo JSON y el JSON traiga otro.
Operaciones
| Recurso | Operaciones |
|---|---|
| Comprobante | Emitir factura · Emitir nota de crédito · Emitir nota de débito · Emitir guía de remisión · Emitir liquidación de compra · Emitir retención 2.0 (recomendada) · Emitir retención 1.0 (obsoleta) · Consultar estado · Esperar autorización · Descargar XML · Descargar PDF · Reprocesar |
| Consulta SRI | Consultar RUC · Consultar cédula · Consultar establecimientos · Buscar por razón social · Consultar RUC o cédula (automático) |
| Crédito | Consultar saldo · Historial (con paginación y filtros por tipo y ambiente) |
| Empresa | Crear · Editar · Subir firma electrónica (.p12) · Subir logo |
| Webhook | Ver · Configurar · Eliminar · Enviar prueba |
Cómo se emite
Cada emisión acepta dos modos:
- Llenar campos: un formulario guiado con el emisor, el comprador o proveedor, los ítems (IVA en lista desplegable), las formas de pago y la información adicional.
- JSON completo: el cuerpo tal como lo documenta la API. Sirve para lo que el formulario no cubre, como los reembolsos de una factura o los «gastos» de una retención 2.0.
Para no repetir trabajo, el nodo resuelve varias cosas por su cuenta:
- Razón social del emisor: obligatoria en la factura (también en modo JSON:
emisor.razon_social). En el formulario, si solo se llena el nombre comercial, se usa como razón social; si faltan ambos, el nodo avisa antes de llamar a la API. - Fecha de emisión: si se deja vacía, pone la fecha de hoy en Ecuador (America/Guayaquil). El SRI no acepta otra fecha.
- Formatos: el secuencial, el establecimiento y el punto de emisión se rellenan con ceros. Los números de documento se aceptan con o sin guiones (
001-001-000000123). Las fechas se aceptan comoAAAA-MM-DDoAAAA/MM/DD. - Respuesta: Invoka registra el comprobante y lo procesa en segundo plano, así que la respuesta trae la clave de acceso y el estado «En procesamiento». Con Opciones → Esperar la autorización, el nodo consulta cada pocos segundos hasta que el SRI autorice o rechace, y devuelve el estado final con los enlaces al XML y al PDF. Si además se activa Fallar si no se autoriza, el flujo se detiene cuando el SRI rechaza el comprobante.
- Notas a consumidor final: el SRI no autoriza notas de crédito ni de débito a CONSUMIDOR FINAL. Invoka las acepta igual y luego el SRI las devuelve, con el secuencial ya gastado. El nodo las frena antes de enviarlas.
- Errores: Invoka contesta algunos errores de validación con HTTP 200 y
creado: false. El nodo los convierte en errores de n8n con el mensaje de Invoka y una pista de qué hacer (por ejemplo, para «Empresa No existe», «Clave de Acceso ya existe» o una fecha que no es la de hoy).
Invoka no genera el secuencial. Lleve usted la numeración de cada establecimiento y punto de emisión, por ejemplo con un contador en una base de datos o en una hoja de cálculo.
Selector dinámico
En Consultar, Esperar, XML, PDF y Reprocesar, el comprobante se puede escribir (clave de acceso de 49 dígitos) o elegir de una lista reciente. Esa lista sale del historial de créditos (comprobantes de producción) y de las últimas 10 entregas del webhook. La API de Invoka no tiene un listado de comprobantes ni de empresas, así que el RUC del emisor se escribe o se toma de un nodo anterior.
Invoka Trigger
⚠ Invoka tiene un solo webhook por cuenta.
Al activar el flujo, el Trigger:
- Lee el webhook que la cuenta tenga configurado y lo recuerda.
- Pone la URL de n8n en su lugar. No cambia el secreto: usa el que ya tenía la cuenta, o el que Invoka genere si no había ninguno.
Al desactivar el flujo, por defecto restaura el webhook anterior: la misma URL y el mismo estado activo o inactivo. Si no había ninguno, lo elimina. Si mientras tanto alguien cambió el webhook, no lo toca. En Opciones → Al desactivar puede elegir, en cambio, eliminarlo o dejarlo como está.
Cada aviso se verifica con su firma. Cuando llega la firma V2, se usa esa; si no, la original:
X-Invoka-Signature-V2: t=MOMENTO,v1=HMAC_SHA256(MOMENTO + "." + cuerpo_crudo, secreto)
X-Invoka-Signature: sha256=HMAC_SHA256(cuerpo_crudo, secreto)
Si la firma no coincide, el aviso se rechaza con 401. Con la V2 también se rechazan los avisos cuya marca de tiempo esté a más de 300 segundos del reloj de n8n, para evitar reenvíos (se ajusta en Opciones → Tolerancia de tiempo).
Invoka entrega el secreto completo solo al guardar el webhook; al consultarlo lo muestra enmascarado. Por eso el Trigger guarda el secreto que recibe al activarse. Si alguien cambia el secreto después, escríbalo en Opciones → Secreto, o desactive y vuelva a activar el flujo. Hay filtros por evento (comprobante.autorizado, comprobante.error, webhook.prueba), por ambiente y por RUC emisor. Los avisos que no pasan el filtro se responden con 200 para que Invoka no los reintente.
La salida trae el campo entrega (cabecera X-Invoka-Delivery), que es el mismo en todos los reintentos de un aviso: úselo para no procesar dos veces el mismo aviso.
Invoka necesita una URL pública para avisar; localhost no sirve. Si el aviso no recibe un 2xx, Invoka lo reintenta hasta 5 veces (a los 1, 5, 15, 60 y 180 minutos).
Desarrollo
npm install
npm run build
CI=1 npx eslint nodes credentials # el «n8n-node lint» interactivo se queda esperando
INVOKA_KEY=API_xxx INVOKA_RUC=... INVOKA_ESTAB=001 INVOKA_PTO=001 INVOKA_CLAVE=<clave> npm run probar
scripts/probar.mjs carga dist/ y prueba contra Invoka de verdad. Las emisiones (INVOKA_EMITIR=1, siempre en ambiente de pruebas), las consultas SRI (INVOKA_SRI=1) y el ciclo real del webhook (PROBAR_WEBHOOK=1) solo corren si se piden con su bandera.
Licencia
MIT