oneapi
Autentificare
Anaf v1 / e-Factura

Citeşte factura

Dintr-o factură CIUS-RO scoate datele de business în JSON, cu aceleaşi chei pe care le-ai trimite la build. Pentru a citi facturile primite fără să umbli în XML.

POST
https://oneapi.ro/api/anaf/v1/efactura/parse

Corpul cererii

Corpul cererii e documentul întreg, trimis brut (Content-Type: application/xml) — nu un obiect cu câmpuri.

Factură UBL CIUS-RO

efactura.xml application/xml · 4,0 KB — se trimite ca atare, în corpul cererii.

Factură corectată

efactura-corectata.xml application/xml · 4,0 KB — se trimite ca atare, în corpul cererii.

Notă de credit

efactura-stornare.xml application/xml · 3,6 KB — se trimite ca atare, în corpul cererii.

Factură în euro

efactura-intracomunitara.xml application/xml · 4,2 KB — se trimite ca atare, în corpul cererii.

Parametri de interogare

Ruta nu acceptă parametri de interogare.

Cum se comportă

  • Documentul se poate trimite şi ca fişier: multipart/form-data cu câmpul fisier (curl -F fisier=@document.xml), în locul corpului brut. Conţinutul fişierului devine corpul cererii, deci rezultatul e identic; opţiunile rămân în query string, iar alt câmp de formular lângă fisier dă 422 camp_necunoscut.
  • Primeşte XML-ul unei facturi CIUS-RO şi întoarce JSON-ul de business corespunzător — vânzător, cumpărător, linii, cote, totaluri. Este inversul lui /anaf/v1/efactura/build: împreună fac round-trip-ul JSON ⇄ XML.
  • Folosirea tipică e citirea unei facturi primite: în loc să parsezi UBL-ul de mână, ceri aici structura de business gata extrasă şi lucrezi cu ea. JSON-ul întors are aceeaşi formă pe care o acceptă build, deci o poţi re-genera, modifica sau compara.
  • Round-trip-ul acoperă şi blocurile care se pierdeau înainte: beneficiarul plăţii (BG-10), reprezentantul fiscal (BG-11), documentele ataşate (BG-24, cu conţinutul base64), avansul încasat şi rotunjirea de plată.
  • Excepţia e cursul de schimb: UBL nu îl scrie explicit, aşa că îl deducem din perechea de cac:TaxTotal (TVA în valuta facturii şi acelaşi TVA în lei). Iese exact la 4 zecimale doar când TVA-ul e diferit de zero; la o factură cu TVA 0 (livrare intracomunitară, export) nu avem din ce să-l deducem şi lipseşte — iar build îl va cere înapoi, explicit.
  • Zero retenţie: XML-ul primit nu se scrie şi nu se loghează; parsarea e stateless, in-memory.
  • Un XML care nu se poate parsa (nu e well-formed sau nu e o factură CIUS-RO recognoscibilă) întoarce 422 în formatul comun {eroare:{cod,mesaj,camp}}.

La ce folosește

  • Citirea unei facturi primite de la un furnizor, fără a scrie parser de UBL.
  • Round-trip: parsezi o factură, modifici un câmp, o re-generezi cu build.
  • Extragerea totalurilor şi a liniilor pentru import într-un sistem contabil.

Structura răspunsului

CâmpTipDescriere
data object JSON-ul de business al facturii — aceeaşi formă acceptată de build (vânzător, cumpărător, linii, cote, totaluri).
data.type string Tipul documentului cerut.
data.number string
data.issue_date string
data.due_date string
data.currency string
data.supplier.name string
data.supplier.vat_id string
data.supplier.address.street string
data.supplier.address.city string
data.supplier.address.county string
data.supplier.address.country string
data.customer.name string
data.customer.vat_id string
data.customer.address.street string
data.customer.address.city string
data.customer.address.county string
data.customer.address.country string
data.lines[].id string
data.lines[].name string
data.lines[].quantity integer
data.lines[].unit string
data.lines[].unit_price integer
data.lines[].vat.rate integer
data.lines[].vat.category string
meta.generat_la string Momentul la care s-a construit răspunsul (ISO 8601).

Exemple de răspuns

body: @efactura.xml

POSThttps://oneapi.ro/api/anaf/v1/efactura/parse
{
    "data": {
        "type": "invoice",
        "number": "FCT-2026-0142",
        "issue_date": "2026-09-10",
        "due_date": "2026-10-10",
        "currency": "RON",
        "supplier": {
            "name": "Exemplu Furnizor SRL",
            "vat_id": "RO990000005",
            "address": {
                "street": "Str. Memorandumului 28",
                "city": "Cluj-Napoca",
                "county": "RO-CJ",
                "country": "RO"
            }
        },
        "customer": {
            "name": "Exemplu Client SRL",
            "vat_id": "RO990000072",
            "address": {
                "street": "Calea Victoriei 1",
                "city": "SECTOR1",
                "county": "RO-B",
                "country": "RO"
            }
        },
        "lines": [
            {
                "id": "1",
                "name": "Servicii de consultanţă",
                "quantity": 2,
                "unit": "H87",
                "unit_price": 100,
                "vat": {
                    "rate": 21,
                    "category": "S"
                }
            }
        ]
    },
    "meta": {
        "generat_la": "2026-10-06T23: 59: 42+03: 00"
    }
}

Coduri de eroare

CodSlugCând apare
401neautentificatToken lipsă, invalid, expirat sau revocat.
403feature_indisponibilPlanul curent nu include funcţia de care ţine ruta.
422xml_invalidCorpul nu e XML parsabil sau nu e o factură CIUS-RO recognoscibilă.
429cota_depasitaCota lunară a planului a fost depăşită (vezi Retry-After).

Erorile modulului Anaf au acelaşi plic ca restul platformei, cu două câmpuri în plus: {eroare: {cod, mesaj, camp, request_id}}. eroare.cod e stabil şi e cel după care ramifici în cod; la validare (422) codul e specific cazului: xml_invalid, xml_nu_e_factura, unitate_necunoscuta, luna_invalida ş.a. camp arată câmpul vinovat, când se poate identifica.

{
    "eroare": {
        "cod": "xml_invalid",
        "mesaj": "Corpul nu e XML parsabil sau nu e o factură CIUS-RO recognoscibilă.",
        "camp": null,
        "request_id": "0199c1f0-6e1a-7c3d-9b2f-4a8e5d1c7b04"
    }
}