Estándares técnicos del emisor / receptor

Requisitos que el software emisor/receptor electrónico debe cumplir según la Descripción Técnica de Servicios Emisores Electrónicos de la DGII.

Estándares técnicos del emisor / receptor

Requisitos que el software del emisor/receptor electrónico debe cumplir (Descripción Técnica Servicios Emisores Electrónicos, DGII). El proceso de alta/certificación, secuencias y ambientes está en la sección Autenticación/Emisión de esta API y en la guía de la DGII.

Naming de archivos XML

FormatoNombreEjemplo
e-CFRNCEmisor+eNCF101672919E310000000001.xml
Aprobación Comercial (ACECF)RNCComprador+eNCF101672919E310000000001.xml
Acuse de recibo (ARECF)RNCComprador+eNCF101672919E310000000001.xml
Resumen Factura Consumo (RFCE)RNCEmisor+eNCF101672919E320000000001.xml

Restricciones de caracteres

En campos ALFANUM, escapar: " → &quot;, ' → &apos;, < → &lt;, > → &gt;, & → &amp; (además &copy;, &euro;, &reg;). En el QR (URL), reemplazar caracteres reservados por su hex (%20, %26, …). No incluir tags vacíos — provocan rechazos.

Firmado de XML

  • Algoritmo SHA-256; firmar con preservewhitespace = false.
  • El campo SN del certificado debe corresponder al RNC/Cédula/Pasaporte del titular.
  • Una vez firmado, el XML no puede alterarse.

Servicios que un receptor debe exponer

Mismo path estandarizado; solo cambia el host (publicado en el Directorio). Deben usar HTTPS, puertos estándar, rutas no sensibles a mayúsculas, accesibles desde internet.

  • Recepción (obligatorio) — POST /fe/recepcion/api/ecf (multipart/form-data, campo xml) → responde el ARECF firmado.
  • Aprobación comercial (obligatorio) — POST /fe/aprobacioncomercial/api/ecf (multipart, xml) → HTTP 200/400.
  • Autenticación (opcional) — GET /fe/autenticacion/api/semilla + POST /fe/autenticacion/api/validacioncertificado → token Bearer para los endpoints anteriores.

Los XSD de referencia están publicados por la DGII. El emisor debe mantener la compatibilidad de sus servicios en el tiempo.

Más en el portal