Recibir e-CF

Recibir también es una obligación. Cuando un proveedor te emite un e-CF, tienes que acusar recibo y después decidir si lo apruebas o lo rechazas comercialmente. FiscalFlow hace lo primero solo; lo segundo es tuyo.

Como llegan los documentos

FiscalFlow funciona como tu endpoint de recepción ante la DGII: las URLs publicadas en el directorio de la DGII para tu RNC apuntan a esta plataforma. Un proveedor consulta el directorio, encuentra esas URLs y te transmite el e-CF directamente. Tu no expones nada.

Al recibir un documento, FiscalFlow genera y firma el ARECF (acuse de recibo) automáticamente y lo devuelve al emisor. Esto ocurre sin que hagas nada y no es configurable: es la respuesta que la DGII exige dentro de la ventana de tiempo del acuse.

Para ver qué URLs tiene publicadas un RNC, incluido el tuyo:

GET /api/v1/directory/{rnc}

curl https://api.fiscalflowsupport.com/api/v1/directory/101000000 \
  -H "X-API-Key: ffs_live_ejemplodeclavenoreal000000000000000000"

200 Response

{
  "success": true,
  "data": {
    "rnc": "101000000",
    "name": "MI EMPRESA SRL",
    "enabled": true,
    "urls": {
      "reception": "https://api.fiscalflowsupport.com/api/v1/mi-empresa/fe/recepcion/api/ecf",
      "acknowledgment": "https://api.fiscalflowsupport.com/api/v1/mi-empresa/fe/acuserecibo/api/ecf",
      "commercial_approval": "https://api.fiscalflowsupport.com/api/v1/mi-empresa/fe/aprobacioncomercial/api/ecf"
    }
  }
}

Un RNC que no está en el directorio devuelve 200 con enabled: false y urls: null: sirve para comprobar, antes de emitirle, si un cliente ya está en facturación electrónica.

Cambio incompatible en 2.0.0. Este endpoint era público y ahora exige API key. La consulta se autentica contra la DGII con un certificado digital, y hasta 1.1.5 usaba el primer certificado que encontrara en la plataforma: cualquiera en internet hacía que firmáramos una sesión con el certificado de un cliente que no era él, bajo su identidad y contra su cuota. Ahora se usa el certificado de tu empresa. Si llamabas sin X-API-Key, agrégala. Si tu empresa todavía no tiene certificado cargado, la respuesta es 503.

El buzón

curl -H "X-API-Key: ffs_live_ejemplodeclavenoreal000000000000000000" \
  https://api.fiscalflowsupport.com/api/v1/inbox

200 Response

{
  "success": true,
  "data": {
    "current_page": 1,
    "per_page": 25,
    "total": 84,
    "data": [
      {
        "uuid": "3b8e1f52-9c4d-4a6b-8f10-2d7e5c9a1b34",
        "environment": "ecf",
        "encf": "E310000000915",
        "rnc_emisor": "130000001",
        "rnc_comprador": "101000000",
        "tipo_ecf": "31",
        "monto_total": "23600.00",
        "issue_date": "2026-08-13",
        "status": 0,
        "approval_status": null,
        "received_at": "2026-08-13T18:44:02+00:00",
        "file_name": "130000001E310000000915.xml",
        "xml_content": "<?xml versión=\"1.0\"?>..."
      }
    ]
  }
}

Fíjate en la forma: el paginador va dentro de data, así que los documentos están en data.data, no en data. Es distinto del listado de emisión, que devuelve un arreglo plano con meta. Y cada elemento incluye el xml_content completo: una página de 25 documentos pesa varios megabytes. Si solo quieres los encabezados, quedate con los campos que necesites y descarta el resto del lado del cliente.

El buzón abarca todas las empresas de tu organización, no solo la de tu key. Filtra por rnc_comprador si administras varios RNC. No admite parámetros de consulta: la paginación es lo único que controlas, con ?page=.

GET /api/v1/inbox/{uuid} devuelve un documento con su acuse y, si ya la hubo, su aprobación comercial.

status es el estado del acuse, no del documento: 0 significa e-CF recibido y 1, e-CF no recibido. La decisión comercial va aparte, en approval_status.

Aprobación comercial

El ACECF es un paso distinto del acuse: el acuse dice "lo recibi", la aprobación comercial dice "estoy de acuerdo con lo que dice". Se envía al emisor con tu certificado digital, así que la empresa receptora necesita tener uno cargado.

curl -X POST \
  -H "X-API-Key: ffs_live_ejemplodeclavenoreal000000000000000000" \
  https://api.fiscalflowsupport.com/api/v1/inbox/3b8e1f52-9c4d-4a6b-8f10-2d7e5c9a1b34/approve

200 Response

{
  "success": true,
  "message": "e-CF approved commercially.",
  "data": {
    "encf": "E310000000915",
    "status": 1,
    "file_name": "101000000E310000000915.xml",
    "commercial_approval_at": "2026-08-14T09:30:12+00:00",
    "approval_source": "manual"
  }
}

Rechazar lleva el mismo camino, con un motivo opcional de hasta 500 caracteres:

curl -X POST \
  -H "X-API-Key: ffs_live_ejemplodeclavenoreal000000000000000000" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Cantidades no coinciden con la orden de compra 4471"}' \
  https://api.fiscalflowsupport.com/api/v1/inbox/3b8e1f52-9c4d-4a6b-8f10-2d7e5c9a1b34/reject

Tras cualquiera de las dos, el approval_status del documento en el buzón queda en approved o rejected. Es una decisión de una sola vez.

Si la empresa receptora no tiene certificado digital cargado, la aprobación falla con 422 y el mensaje Company not found for this reception.. Un fallo al firmar o al transmitir devuelve 500 con Failed to approve: y el detalle. Ninguna de las dos respuestas usa el sobre de error.code del resto de la API.

Enterarte de que llegó algo

En vez de sondear el buzón, suscríbete al webhook document.reception.received. Se dispara en cuanto un e-CF entra:

{
  "event": "document.reception.received",
  "company_id": 12,
  "encf": "E310000000915",
  "rnc_emisor": "130000001",
  "tipo_ecf": "31",
  "monto_total": 23600.00,
  "timestamp": "2026-08-13T18:44:02+00:00"
}

Y document.approval.created te avisa cuando se registra una aprobación comercial. Ver Webhooks.

La recepción y el acuse están incluidos en todos los planes, incluido Receptor. La emisión no.