AuthorizationFailedException

Documentat în ghidul de integrare SFS.

Apelul către API-ul SIA „e-Factura” returnează AuthorizationFailedException. Este o eroare diferită de cea de autentificare: nu spune că nu ați fost recunoscut, ci că procesul de autorizare a eșuat.

Ce spune ghidul

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

Aceasta este singura descriere din ghid. Nu există o listă a permisiunilor, a rolurilor sau a condițiilor în care autorizarea eșuează.

Autentificare și autorizare nu sunt același lucru

• Autentificarea stabilește cine sunteți — credențialele sunt sau nu acceptate. Vedeți AuthenticationFailedException.
• Autorizarea stabilește dacă ceea ce cereți vă este permis.

Dacă primiți această eroare, credențialele au trecut. Problema este în ce încercați să faceți sau asupra cui.

O nelămurire pe care nu o putem rezolva

Merită spusă, pentru că oricine ajunge aici o va avea.

Ghidul precizează, la capitolul despre crearea utilizatorului API, că acesta „are un rol special, care îi conferă acces la toate funcționalitățile prevăzute de platformă”.

Dacă utilizatorul API are acces la toate funcționalitățile, nu este evident ce anume poate să eșueze la autorizare. Ghidul nu explică. Ipoteze există — de exemplu că restricția ar ține de datele accesate, nu de funcția apelată — dar sunt ipotezele noastre, nu ceva scris în document, și nu le prezentăm ca răspuns.

Pentru ce declanșează efectiv această eroare, verificați la SFS.

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).

Cele două canale de eroare

Ca și celelalte excepții, aceasta este documentată în tabelele „Erori” ale celor opt metode de citire: CheckInvoicesStatus, GetAcceptedInvoices, GetInvoicesBySeriaNumber, GetInvoicesContentForPrint, GetInvoicesForSigning, GetInvoicesQRcodes, GetTaxpayersInfo, SearchInvoices.

Metodele de transmitere (PostInvoices și celelalte Post*) nu au tabele de erori în ghid — ele raportează eșecul prin Status = 3 și ErrorMessage. Tratați ambele canale, altfel eșecurile la transmitere trec neobservate.

Ce puteți verifica

1. Rolul contului: utilizatorul API se creează de către Managerul companiei (procedura).
2. Că apelați în numele companiei pentru care a fost creat utilizatorul.
3. Că ActorRole din cerere corespunde rolului real al companiei în tranzacție — 1 furnizor, 2 cumpărător, 3 transportator.

Punctul 3 este o verificare rezonabilă, nu o cauză documentată. Ghidul nu leagă ActorRole de această eroare.

Payload observat

Nu deținem încă un răspuns capturat de pe platformă pentru acest caz.

Ajută depus?

Nu — depus nu există. Nu am făcut niciodată un apel către această platformă.

Vezi și

• AuthenticationFailedException
• 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