Soluciones · Por API

Para integradores: por API.

Para empresas de software y contadores que ya tienen la relación con el cliente. Tu sistema manda el comprobante como JSON y recibe el estado. Si ya hablas con un proveedor, lo que cambia es la dirección y la llave, no tu código.

Ejemplo
curl -X POST "$HOST/dom/v1/invoices" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d @comprobante.json

200 · la respuesta

{
  "id": "01JB7Q…",
  "status": "FINISHED",
  "legalStatus": "ACCEPTED",
  "encf": "E320000000123",
  "securityCode": "Xk3pQ9",
  "documentStampUrl": "https://ecf.dgii.gov.do/…",
  "xml": "$HOST/dom/v1/invoices/01JB7Q…/xml",
  "pdf": "$HOST/dom/v1/invoices/01JB7Q…/pdf"
}
/ Los diez tipos[ 01 / 03 ]

Del 31 al 47. Las mismas rutas del mercado.

Los diez tipos de comprobante, validados contra los esquemas oficiales. Las rutas son las mismas que usan los proveedores del mercado: migrar es cambiar la dirección y la llave.

/ Cómo se trabaja[ 02 / 03 ]

Tu panel y tus empresas

Cada integrador con su panel y las empresas que atiende.

Los certificados, donde firmes

En custodia nuestra o en la tuya, según cómo firme cada contribuyente.

La respuesta, cruda

Lo que contesta la DGII se guarda tal cual, sin resumir.

Enlaces que no vencen

El XML y el PDF se sirven desde el archivo, no desde un enlace que caduca a la hora.

Dónde está hoy

El módulo está construido y probado contra el ambiente de pruebas de la DGII; la emisión en producción sale hoy por un proveedor certificado. Se cotiza por volumen. Ver el módulo ante la DGII ↗

/ Por API · [ 03 / 03 ]

¿Ya hablas con un proveedor? Cambia la dirección y la llave.

La API tiene la misma forma que la de los proveedores del mercado: lo que cambia es la dirección y la llave, no tu código.