Recibir un e-CF

Si además de emitir necesitas recibir e-CF de tus proveedores, NovaFE expone el endpoint que la DGII exige para eso, valida cada comprobante que llega, y responde con el Acuse de Recibo (ARECF) firmado, en la misma petición.

El endpoint

POST /{tenantid}/fe/recepcion/api/ecf

Es una ruta fija que exige la DGII: no lleva versión de la API, y el contribuyente que te manda un comprobante identifica tu tenant por el {tenantid} de la URL, no por una API key tuya. El cuerpo es multipart/form-data, con el <ECF> completo en el campo xml. La respuesta es el <ARECF> firmado, siempre en la misma petición: nunca se difiere a un proceso de fondo.

Qué determina la respuesta

Situación	Respuesta
XML mal formado, e-NCF o RNC emisor irreconocibles, tu tenant no existe o no tiene certificado activo	400, sin ARECF
Tipo de e-CF fuera de 31, 33, 34 o 44, o no pasa el XSD	ARECF con Estado=1, motivo 1 (Error de Especificación)
La firma del comprobante no es válida	ARECF con Estado=1, motivo 2 (Error de Firma Digital)
Mismo emisor y e-NCF que un envío anterior, pero con contenido distinto	ARECF con Estado=1, motivo 3 (Envío Duplicado)
El RNC del comprador en el comprobante no es el tuyo	ARECF con Estado=1, motivo 4 (RNC Comprador no Corresponde)
Mismo emisor, e-NCF y contenido que un envío anterior (reintento exacto)	Se reenvía el mismo ARECF ya firmado antes
Ninguna objeción	ARECF con Estado=0

Cada intento fallido que sí llega a producir un ARECF (Estado=1) dispara el webhook inbound_ecf.received, igual que uno aceptado: este evento avisa que algo llegó y cómo se resolvió, no solo los casos exitosos.

La verificación de firma no valida la cadena de confianza

NovaFE confirma que la firma del XML sea criptográficamente válida contra el certificado embebido en el comprobante, pero todavía no valida que ese certificado venga de una autoridad certificadora autorizada por la DGII o INDOTEL, ni que no esté revocado. Es un gap conocido, compartido con la verificación de firma en general.

Autenticación B2B opcional

Por defecto, cualquiera puede mandarte un comprobante a este endpoint sin credencial: el ARECF firmado ya es constancia suficiente de la recepción. Si prefieres exigir una credencial antes de aceptar un envío:

PUT /api/v1/settings/inbound.require_bearer_auth
{ "value": "true" }

(El endpoint anterior, PUT /api/v1/inbound-ecf-settings con { "requireBearerAuth": true }, sigue funcionando y hace lo mismo.)

Con esto activado, quien te envía un comprobante primero tiene que pedir una semilla y validarse con su propio certificado:

GET  /{tenantid}/fe/autenticacion/api/semilla
POST /{tenantid}/fe/autenticacion/api/validacioncertificado

La segunda llamada devuelve un token temporal que va como Authorization: Bearer en el envío del comprobante. Sin ese token (con la opción activada), POST /fe/recepcion/api/ecf responde 401 antes de mirar el contenido del XML.