AuthenticationFailedException

Documentat în ghidul de integrare SFS.

Apelul către API-ul SIA „e-Factura” returnează AuthenticationFailedException. Ghidul indică un singur motiv: procesul de autentificare a eșuat — adică sistemul nu a acceptat perechea utilizator/parolă cu care ați apelat.

Ce spune ghidul

Ghidul de integrare listează această eroare în tabelele „Erori” ale metodelor, cu motivul:

„Procesul de autentificare al consumatorului serviciului a eșuat."

Atât. Nu există în ghid o listă de cauze concrete, un cod numeric asociat sau o procedură de remediere — iar noi nu adăugăm una.

O precizare despre formulare

Ghidul nu folosește un text unic pentru motivul acestei erori. Am găsit patru variante de formulare în document, în funcție de metodă — de exemplu, la SearchInvoices motivul este scris mai scurt decât la celelalte. Citatul de mai sus este varianta majoritară.

Nu deduceți din asta că există patru erori diferite: codul este același. Este o inconsecvență de redactare a documentului, catalogată în auditul intern al ghidului, §5 (document de lucru, nepublicat).

Pe ce metode este documentată

Tabelele „Erori” apar la opt dintre metodele descrise în ghid, toate de citire: CheckInvoicesStatus, GetAcceptedInvoices, GetInvoicesBySeriaNumber, GetInvoicesContentForPrint, GetInvoicesForSigning, GetInvoicesQRcodes, GetTaxpayersInfo și SearchInvoices.

Atenție: sistemul are două canale de eroare diferite

Aceasta este cea mai utilă observație de pe pagină, și se aplică întregii integrări.

• Metodele de citire (cele opt de mai sus) semnalează problemele prin excepții — inclusiv aceasta.
• Metodele de transmitere (PostInvoices, PostInvoicesWithAttachment, PostCanceledInvoices, PostAcceptedInvoices, PostRejectedInvoices) nu au tabele de erori în ghid. Ele semnalează eșecul altfel: prin câmpul Status cu valoarea 3 — eroare la executare — plus ErrorMessage, iar la anulare și prin statutul fiecărei facturi în parte.

Un sistem care tratează doar excepțiile va rata tăcut fiecare eșec la transmitere. Verificați ambele canale.

Ce puteți verifica

Ghidul descrie autentificarea ca nume de utilizator și parolă transmise printr-o conexiune HTTPS, cu returnarea unui token de sesiune. Deci:

1. Credențialele folosite sunt cele ale utilizatorului API, nu ale unui cont de persoană — sunt lucruri diferite (cum se creează un utilizator API).
2. Apelul se face peste HTTPS.
3. Utilizatorul API mai există în Setări → Utilizatorii companiei.

Dacă toate trei sunt în regulă și eroarea persistă, verificați la SFS. Nu știm ce altceva o poate declanșa, pentru că ghidul nu spune.

Payload observat

Nu deținem încă un răspuns capturat de pe platformă pentru acest caz. Textul de mai sus provine din documentație, nu dintr-un apel real.

Ajută depus?

Nu — depus nu există. Nu am făcut niciodată un apel către această platformă, nici reușit, nici eșuat.

Vezi și

• AuthorizationFailedException
• InternalErrorException
• Cum creați un utilizator API în e-Factura (cross-cluster D2)

depus este în dezvoltare.

Verificat la: 2026-08-17

Acest material are caracter informativ și nu constituie consultanță juridică sau fiscală. Pentru situația concretă a companiei dumneavoastră, adresați-vă unui consultant autorizat sau instituției competente.

Stadiu: în recenzie