Modo passthrough: enviar el XML e-CF ya construido¶
Si su sistema ya genera el XML e-CF, puede enviarlo tal cual en vez del JSON canónico. Esta API lo valida, lo firma con el certificado del emisor, lo valida contra el XSD oficial y lo transmite a la DGII, con el mismo seguimiento de estado que la vía JSON.
No tocamos su XML. Lo único que se le añade es la firma digital.
Cómo se activa¶
El mismo endpoint, cambiando el Content-Type:
POST /api/v1/documents/31
Authorization: Bearer {su-token}
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<ECF><Encabezado>…</Encabezado><DetallesItems>…</DetallesItems><FechaHoraFirma>…</FechaHoraFirma></ECF>
Es el mismo recurso en otra representación: application/json → JSON canónico,
application/xml (o text/xml) → passthrough.
Envíelo SIN firmar¶
La firma la aplica esta API con el certificado del emisor. Un XML que ya venga firmado se rechaza: no podemos re-firmar el documento de otro, y la firma del integrador no serviría porque el certificado tiene que corresponder al emisor.
Qué se valida antes de aceptarlo¶
En la vía JSON, el e-NCF lo reservamos nosotros y eso garantiza por construcción que sea correcto. En passthrough el e-NCF lo trae usted, así que se comprueba lo mismo de forma explícita:
| Comprobación | Por qué |
|---|---|
XML bien formado y raíz <ECF> |
Lo mínimo para poder procesarlo |
TipoeCF = tipo de la ruta |
Evita emitir un 32 por la ruta del 31 |
RNCEmisor = RNC de su credencial |
No se firma el comprobante de otro RNC. La DGII lo rechazaría por "firmante no autorizado" |
| El XML no viene firmado | Ver arriba |
eNCF con estructura E + tipo + 10 dígitos |
Formato de la norma |
| El e-NCF está en una secuencia autorizada, activa y no vencida | No se puede emitir fuera de su rango |
| El e-NCF no se ha usado ya | Un duplicado es un rechazo seguro |
| El e-NCF no pertenece a un rango anulado | "No pudiéndose utilizar posteriormente secuencias que sí hayan podido ser anuladas" |
Cualquiera de ellas devuelve 422 con el motivo concreto, sin consumir nada.
La fecha de emisión es la del XML¶
En la vía JSON sellamos la fecha al recibir el comprobante. En passthrough manda la FechaEmision que
usted declara: es la que la DGII va a ver y con la que recalcula sus reglas (por ejemplo la de los 30
días de la nota de crédito). Asegúrese de que sea la real.
Factura de consumo por debajo de RD$250.000¶
También en passthrough se transmite como resumen (RFCE), igual que en la vía JSON: se firma y conserva su e-CF completo, y del XML que envió se extraen los datos del resumen para remitirlo al servicio que corresponde. No tiene que construir el RFCE usted.
Respuesta¶
Idéntica a la de la vía JSON: 202 con el document_id, el e-NCF y el estado interno. A partir de ahí
el ciclo es el mismo — sondeo del TrackID, representación impresa y consulta por
GET /api/v1/documents/{eNCF}.