e-Factura da ANAF (Roménia) pela API

Para a Roménia: pré-validação CIUS-RO, submissão ao SPV, estado normalizado, resposta assinada e caixa de faturas recebidas.

Para a Roménia: pré-validação CIUS-RO, submissão ao SPV, estado normalizado, resposta assinada e caixa de faturas recebidas.

← Voltar à documentação da API

A primeira fatura em 6 passos

  1. Execute POST /v1/invoices/{id}/efactura/validate. A validação prévia CIUS-RO (Roménia) não envia nada à ANAF e indica-lhe exatamente o que seria rejeitado.
  2. Submeta-a com POST /v1/invoices/{id}/efactura/submit, sempre com uma Idempotency-Key. Recebe um submission_id e um status.
  3. Consulte GET /v1/efactura/submissions/{id} até chegar a accepted ou rejected.
  4. Force uma nova consulta à ANAF (Roménia) com POST /v1/efactura/submissions/{id}/refresh — conta para o limite de 10 por minuto.
  5. Descarregue o arquivo com a resposta assinada da ANAF (Roménia) através de GET /v1/efactura/submissions/{id}/download.

Todos os endpoints

MétodoEndpointScopeIdempotency-KeyPedidos / minuto
GET/invoices/{invoice_id}/xml
Descarregar o XML UBL / CIUS-RO (Roménia)
invoices:read—120
POST/invoices/{invoice_id}/efactura/validate
Pré-verificação CIUS-RO (Roménia) — validar sem enviar
efactura:read—120
POST/invoices/{invoice_id}/efactura/submit
Enviar a fatura para a ANAF (SPV, Roménia)
efactura:submitobrigatório10
GET/efactura/submissions
Listar os envios para a ANAF (Roménia)
efactura:read—120
GET/efactura/submissions/{submission_id}
Obter um envio
efactura:read—120
POST/efactura/submissions/{submission_id}/refresh
Consultar a ANAF (Roménia) sobre o estado atual
efactura:read—10
GET/efactura/submissions/{submission_id}/download
Descarregar o ficheiro da resposta assinada
efactura:read—120
GET/efactura/inbox
Faturas de fornecedores recebidas através do SPV (Roménia)
efactura:read—120
GET/efactura/inbox/{inbound_id}
Obter uma fatura recebida
efactura:read—120
GET/efactura/inbox/{inbound_id}/download
Descarregar o ficheiro da fatura recebida
efactura:read—120
POST/efactura/inbox/sync
Obter as novas mensagens do SPV (ANAF, Roménia) para a caixa de entrada
efactura:read—10

O que é a API 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,
# por isso /inbox/sync conta para o limite de envio de 10/min. Agende-o com cron, não faça polling.

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

O circuito ANAF e-Factura (Roménia)

not_sentvalidatingqueuedsentprocessingacceptedrejectederror

Erros

EstadoTipoCódigo
422invalid_request_errorcius_ro_incomplete

Erros frequentes

  • Ciclo de vida normalizado: not_sent → validating → queued → sent → processing → accepted | rejected | error.
  • accepted significa transmitida legalmente. rejected significa que o sistema nacional de faturação eletrónica (na Roménia: ANAF) a recusou: corrija e submeta novamente. error é uma falha de transporte do nosso lado e pode ser repetida em segurança.
  • A submissão é irreversível: uma segunda cópia da mesma fatura não pode ser retirada do sistema nacional de faturação eletrónica. É por isso que a Idempotency-Key é obrigatória.
  • GET /v1/invoices/{id}/xml fornece o XML UBL / CIUS-RO (o perfil romeno) sem qualquer submissão — para o seu próprio arquivo ou para uma auditoria.
  • Caixa de entrada: POST /v1/efactura/inbox/sync obtém as novas mensagens, GET /v1/efactura/inbox lista-as e /download obtém o arquivo de cada fatura recebida.
  • Os endpoints de e-Factura só funcionam para tenants romenos; caso contrário, recebe um 404.

Perguntas e respostas para desenvolvedores

Quanto tempo demora a ANAF (Roménia) a aceitar uma fatura?

Varia, de segundos a horas. Não bloqueie a venda: submeta de forma assíncrona e trate accepted e rejected como eventos.

Posso obter o XML CIUS-RO (Roménia) sem enviar nada à ANAF?

Sim. GET /v1/invoices/{id}/xml gera o documento sem submissão, e /efactura/validate com include_xml=true devolve-o codificado em base64.

Com que frequência posso executar inbox/sync?

No máximo 10 chamadas por minuto, mas, na prática, na Roménia, a ANAF permite aproximadamente uma chamada de listagem de mensagens por minuto e por CIF. Execute-o a partir de um cron, de poucos em poucos minutos.

O que faço se o estado ficar em error?

error é uma falha de transporte ou de autenticação do nosso lado, pelo que pode ser repetida em segurança. Se persistir, envie o request_id ao suporte.