e-Factura de ANAF (Rumanía) por la API

Para Rumanía: verificación CIUS-RO, envío al SPV, estado normalizado, respuesta firmada y bandeja de facturas recibidas.

← Volver a la documentación de la API

Tu primera factura en 6 pasos

Ejecuta POST /v1/invoices/{id}/efactura/validate. La validación previa CIUS-RO (Rumanía) no envía nada a ANAF y te indica exactamente qué se rechazaría.
Preséntala con POST /v1/invoices/{id}/efactura/submit, siempre con una Idempotency-Key. Recibes un submission_id y un status.
Consulta GET /v1/efactura/submissions/{id} hasta que llegue a accepted o rejected.
Fuerza una nueva consulta a ANAF (Rumanía) con POST /v1/efactura/submissions/{id}/refresh: cuenta contra el cupo de 10 por minuto.
Descarga el archivo con la respuesta firmada de ANAF (Rumanía) mediante GET /v1/efactura/submissions/{id}/download.

Todos los endpoints

Método	Endpoint	Scope	Idempotency-Key	Peticiones / minuto
GET	/invoices/{invoice_id}/xml Descargar el XML UBL / CIUS-RO (Rumanía)	invoices:read	—	120
POST	/invoices/{invoice_id}/efactura/validate Preflight CIUS-RO (Rumanía) — validar sin enviar	efactura:read	—	120
POST	/invoices/{invoice_id}/efactura/submit Enviar la factura a ANAF (SPV, Rumanía)	efactura:submit	obligatorio	10
GET	/efactura/submissions Listar los envíos a ANAF (Rumanía)	efactura:read	—	120
GET	/efactura/submissions/{submission_id} Obtener un envío	efactura:read	—	120
POST	/efactura/submissions/{submission_id}/refresh Consulta a ANAF (Rumanía) el estado actual	efactura:read	—	10
GET	/efactura/submissions/{submission_id}/download Descargar el archivo de la respuesta firmada	efactura:read	—	120
GET	/efactura/inbox Facturas de proveedor recibidas a través del SPV (Rumanía)	efactura:read	—	120
GET	/efactura/inbox/{inbound_id} Obtener una factura recibida	efactura:read	—	120
GET	/efactura/inbox/{inbound_id}/download Descargar el archivo de la factura recibida	efactura:read	—	120
POST	/efactura/inbox/sync Traer los mensajes nuevos del SPV (ANAF, Rumanía) a la bandeja	efactura:read	—	10

Qué es la API de 4invoices

bash
# CIUS-RO preflight. Sends NOTHING to ANAF.
curl -sS -X POST "https://api.4invoices.net/v1/invoices/inv_01J7ABC/efactura/validate?include_xml=true" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

# → {"invoice_id":"inv_01J7ABC","valid":false,
#    "errors":["buyer.county is required for RO buyers"],
#    "xml_base64":"PD94bWwg..."}

bash
curl -sS -X POST https://api.4invoices.net/v1/invoices/inv_01J7ABC/efactura/submit \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Idempotency-Key: efactura-inv_01J7ABC-1'

# → {"submission_id":"sub_01J7XYZ","status":"queued"}

python
import time, requests

BASE = "https://api.4invoices.net/v1"
TERMINAL = {"accepted", "rejected"}
H = {"Authorization": f"Bearer {token}"}

def wait_for_anaf(submission_id, timeout=900):
    deadline = time.time() + timeout
    delay = 15
    while time.time() < deadline:
        r = requests.get(f"{BASE}/efactura/submissions/{submission_id}", headers=H, timeout=30)
        r.raise_for_status()
        status = r.json()["status"]
        if status in TERMINAL:
            return r.json()
        # /refresh asks ANAF directly and shares the 10/min submit bucket.
        requests.post(f"{BASE}/efactura/submissions/{submission_id}/refresh", headers=H, timeout=30)
        time.sleep(delay)
        delay = min(delay * 2, 120)
    raise TimeoutError(submission_id)

bash
# Pull new SPV messages, then read the inbound supplier invoices.
curl -sS -X POST https://api.4invoices.net/v1/efactura/inbox/sync \
  -H "Authorization: Bearer $ACCESS_TOKEN"

curl -sS "https://api.4invoices.net/v1/efactura/inbox?limit=50" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

# ANAF allows roughly ONE message-list call per minute per CIF,
# así que /inbox/sync cuenta en el cupo de envío de 10/min. Programa su ejecución con cron, no hagas polling.

https://api.4invoices.net/v1 · https://api.4invoices.net/v1/openapi.json

El circuito ANAF e-Factura (Rumanía)

Errores

Estado	Tipo	Código
422	invalid_request_error	cius_ro_incomplete

Errores frecuentes

Ciclo de vida normalizado: not_sent → validating → queued → sent → processing → accepted | rejected | error.
accepted significa transmitida legalmente. rejected significa que el sistema nacional de facturación electrónica (en Rumanía: ANAF) la ha rechazado: corrígela y vuelve a presentarla. error es un fallo de transporte por nuestra parte y se puede reintentar con seguridad.
La presentación es irreversible: una segunda copia de la misma factura no se puede retirar del sistema nacional de facturación electrónica. Por eso la Idempotency-Key es obligatoria.
GET /v1/invoices/{id}/xml te da el XML UBL / CIUS-RO (el perfil rumano) sin presentar nada: para tu propio archivo o para una auditoría.
Bandeja de entrada: POST /v1/efactura/inbox/sync trae los mensajes nuevos, GET /v1/efactura/inbox los lista y /download descarga el archivo de cada factura recibida.
Los endpoints de e-Factura solo funcionan para tenants rumanos; en caso contrario recibes un 404.

Preguntas y respuestas para desarrolladores

¿Cuánto tarda ANAF (Rumanía) en aceptar una factura?

Varía, de segundos a horas. No bloquees la venta: presenta de forma asíncrona y trata accepted y rejected como eventos.

¿Puedo obtener el XML CIUS-RO (Rumanía) sin enviar nada a ANAF?

Sí. GET /v1/invoices/{id}/xml genera el documento sin presentarlo, y /efactura/validate con include_xml=true lo devuelve codificado en base64.

¿Con qué frecuencia puedo ejecutar inbox/sync?

Como máximo 10 llamadas por minuto, pero en la práctica, en Rumanía, ANAF permite aproximadamente una llamada de listado de mensajes por minuto y por CIF. Ejecútalo desde un cron, cada pocos minutos.

¿Qué hago si el estado se queda en error?

error es un fallo de transporte o de autenticación por nuestra parte, así que se puede reintentar con seguridad. Si persiste, envía el request_id a soporte.

Ver también