Skip to content
↑↓ navigate ↵ open Esc close
Platform

e-CF lifecycle

When you call POST /api/v1/<resource>, factura.com.do orchestrates signing, submission and acknowledgement polling against the DGII. This page documents the conceptual flow; the internal endpoints of the flow are not a public surface.

Summary

The POST never waits for the DGII acknowledgement. Your integration receives the immediate confirmation and the final status arrives later via webhook. This design protects your latency: the DGII can take seconds or minutes depending on load, and your UI never waits.

Five lifecycle steps

  1. 01

    Request validation

    Types, expiries, tenant permissions. If anything is wrong, factura.com.do returns 400 before touching the DGII.

  2. 02

    XML construction and signing

    Converter selection by e-CF type (E31, E32 RFCE, E44…) and signing with the tenant's digital certificate.

  3. 03

    Submission to the DGII service

    DGIIEcfService or DGIIRFCEService depending on the type. The DGII responds with a trackId and a status code (5/6/7/8).

  4. 04

    Persistence and immediate response

    Document + status + trace are persisted. Your original call receives { documentId, consultationUrl } without waiting for the final acknowledgement.

  5. 05

    Background polling

    DGIIStatusCheckBackgroundService refreshes the statuses of documents in progress. When there is a change, factura.com.do fires the corresponding webhook.

e-CF types and resources

The ten e-CF types the DGII recognizes today map to the public API resources. Internal slices change the converter when signing, but the public contract is uniform.

DGII statuses

The DGII status code travels in the data.StatusId field of the webhook and maps one-to-one with the dgii.* event.

Status Webhook event Meaning
5 dgii.aprobado Document accepted in full
6 dgii.rechazado Document rejected; reconcile with a GET to the resource to read the persisted reason
7 dgii.en_proceso DGII evaluating; polling continues
8 dgii.aceptado_condicional Accepted with observations; log the entry

Certification and signing

These routes support the certification process as an electronic issuer. certifications stores the holder's data and the digital certificate password; certification/run-all generates, signs and sends the test documents to the DGII and responds with a .zip file (with errores.txt if any failed); and sign-xml signs your own XML with the workspace certificate. The last two respond 400 with { message } if no digital certificate is configured. All of them require the Corporativo plan.

POST /api/v1/certifications X-Api-Key Stable

Crea un registro de certificación con los datos del titular. Responde { certificationId, success, message }.

Name Type Description
name body string Required

Nombre del titular.

lastName body string Required

Apellido del titular.

identificationType body integer Required

Tipo de identificación del titular.

countryId body integer Required

País del titular (ver `GET /api/v1/countries-lookup`).

email body string Required

Correo del titular.

phone body string Required

Teléfono del titular.

Next steps

Next step

Continue here