Consultas en vivo contra la DGII¶

Tres endpoints que preguntan a la DGII en el momento, en lugar de leer nuestro registro. Existen porque los dos registros pueden divergir, y cuando divergen el que vale es el de ellos.

Endpoint	Para qué
`GET /api/v1/documents/{eNCF}/dgii-status`	Estado de un e-CF suyo en la DGII, y en qué se diferencia de lo que tenemos
`GET /api/v1/documents/{eNCF}/track-ids`	Los envíos que la DGII registra para ese e-NCF
`GET /api/v1/received-documents/{eNCF}/dgii-status`	Si un comprobante que le enviaron tiene validez fiscal

Todos requieren el token de siempre (Authorization: Bearer …) y sólo devuelven comprobantes del emisor autenticado.

La consulta que conviene conocer: validez fiscal de lo que recibe¶

Cuando un proveedor le envía un e-CF, verificamos su firma digital antes de acusar recibo. Eso no significa que el comprobante sea válido ante la DGII. La firma demuestra quién lo emitió y que no se alteró; que la DGII lo haya aceptado es otra cosa, y puede haberlo rechazado.

Antes de dar por bueno un crédito fiscal:

GET /api/v1/received-documents/E310000000099/dgii-status

{
  "status": "success",
  "data": {
    "encontrado": true,
    "valido_fiscalmente": false,
    "status_code": 6,
    "status": "rejected_dgii",
    "codigo_dgii": 2,
    "estado_dgii": "Rechazado",
    "rnc_emisor": "131880738",
    "e_ncf": "E310000000099",
    "monto_total": 2360.00,
    "total_itbis": 360.00,
    "fecha_emision": "10-08-2026",
    "fecha_firma": "10-08-2026 09:14:22",
    "emisor_rnc": "131880738",
    "acuse_emitido": true,
    "monto_registrado": 2360.00
  }
}

acuse_emitido: true con valido_fiscalmente: false es justo el caso interesante: el comprobante llegó bien y aun así no sustenta nada.

Estado de un e-CF propio, con las discrepancias¶

GET /api/v1/documents/E310000000077/dgii-status

Además de lo que devuelve la DGII, la respuesta trae nuestro_status y una lista discrepancias —vacía cuando todo cuadra:

{
  "status": "success",
  "data": {
    "encontrado": true,
    "valido_fiscalmente": true,
    "status": "accepted_dgii",
    "nuestro_status": "unresolved",
    "monto_total": 1180.00,
    "discrepancias": [
      "El estado en la DGII es \"accepted_dgii\" y aquí está registrado como \"unresolved\"."
    ]
  }
}

Se comparan tres cosas: el estado, el monto total y el código de seguridad. Ese último es el que importa de verdad: sale del hash de la firma, así que si no coincide, el comprobante que la DGII tiene registrado no es el que firmamos aquí.

Cuándo usarla:

Un documento en unresolved (se agotó el sondeo automático) — es la forma de cerrarlo.
Cuadre periódico contra su contabilidad.
Cualquier duda sobre un comprobante del que no le llegó respuesta.

Los envíos de un e-NCF¶

GET /api/v1/documents/E310000000077/track-ids

{
  "status": "success",
  "data": {
    "e_ncf": "E310000000077",
    "nuestro_track_id": "b4c1…",
    "envios": [
      { "track_id": "b4c1…", "estado_dgii": "Aceptado",  "status": "accepted_dgii", "fecha_recepcion": "2026-08-12T09:00:00" },
      { "track_id": "9af0…", "estado_dgii": "Rechazado", "status": "rejected_dgii", "fecha_recepcion": "2026-08-10T09:00:00" }
    ],
    "transmitido_mas_de_una_vez": true
  }
}

Un mismo e-NCF puede tener más de un envío: la propia DGII lo advierte ("se pueden obtener múltiples TrackIds cuando se remiten varios e-CF con el mismo número de comprobante fiscal"). Pasa cuando un envío llega y su respuesta se pierde. Los envíos vienen del más reciente al más antiguo.

No hace falta vigilarlo a mano en el caso normal: antes de retransmitir un comprobante cuyo envío anterior falló, comprobamos si la DGII ya lo tiene y adoptamos su TrackID en lugar de mandarlo otra vez. Este endpoint es para cuando quiere verlo usted.

Errores¶

Código	Cuándo
`404`	El e-NCF no existe para el emisor autenticado
`503`	El servicio de consulta de la DGII no responde — vuelva a intentarlo, no es un error de su petición

Estas consultas no se cachean: el objetivo es saber qué dice la DGII ahora.