import { Aside } from "@astrojs/starlight/components";

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`](/webhooks/catalogo-de-eventos/), igual
que uno aceptado: este evento avisa que algo llegó y cómo se resolvió, no
solo los casos exitosos.

<Aside
  type="note"
  title="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.
</Aside>

## 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:

```json
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.