Autentifică cererile API
Fiecare cerere către API-ul e-bon trebuie să poarte unul dintre două credențiale: o cheie API (pentru integrări server-to-server și parteneri POS) sau un jeton de acces din Portal (pentru utilizatorii autentificați în Portalul e-bon sau în aplicația de pe AMEF). Această pagină arată cum obții fiecare credențial, cum îl trimiți și ce faci când autentificarea eșuează.
Alege metoda de autentificare
| Tu ești… | Folosește acest credențial | Trimis ca |
|---|---|---|
| Un partener POS sau o integrare de back-office | Cheie API | Antet x-api-key: <cheie> sau Authorization: Bearer <cheie> |
| Un utilizator autentificat în Portal sau în aplicația de pe AMEF | Jeton de acces Portal (JWT) | Authorization: Bearer <jeton> |
Cele două credențiale nu sunt interschimbabile. Cheile API sunt legate de o organizație și au permisiuni (scopes). Jetoanele de Portal sunt legate de un utilizator dintr-o organizație și au un rol.
Autentifică cu o cheie API
Cheile API sunt metoda recomandată pentru a apela API-ul e-bon de pe orice server, AMEF sau sistem de back-office. O cheie arată astfel:
ebon_live_{orgId}_{32-hex}
Cheia completă îți este afișată o singură dată, în fereastra în care o creezi. Salveaz-o imediat într-un seif de secrete — e-bon nu mai afișează niciodată secretul complet. Portalul îți va arăta în continuare doar prefixul (totul înainte de coada aleatoare), ca să poți identifica ulterior cheia.
Trimite prima cerere autentificată
Creează o cheie API în Portal
Autentifică-te în Portal, deschide Setări → Chei API, apasă Creează cheie API, pune o etichetă, alege permisiunile de care are nevoie și copiază cheia din fereastra de confirmare.
Adaugă cheia în cerere
Trimite cheia în antetul x-api-key (preferat) sau în Authorization: Bearer …:
POST /api/v1/receipts HTTP/1.1
Host: api.e-bon.ro
Content-Type: application/json
x-api-key: ebon_live_abc123def456_0123456789abcdef0123456789abcdef
{ "deviceId": "dev_…", "items": [ … ] }
Sau, echivalent:
Authorization: Bearer ebon_live_abc123def456_0123456789abcdef0123456789abcdef
Tratează răspunsul
La succes primești resursa înapoi. La eșec de autentificare primești un plic JSON 401 sau 403 — vezi Tratează erorile de autentificare mai jos.
Revocă sau rotește o cheie
Cheile API nu expiră singure. Ca să oprești o cheie, deschide Portalul, găsește cheia după prefix și apasă Revocă. Următoarea cerere care o folosește primește imediat 401 UNAUTHORIZED — API key is inactive..
Nu există rotație în loc. Ca să rotești o cheie, creează una nouă, actualizează seiful de secrete, apoi revoc-o pe cea veche după ce noua versiune a fost lansată.
Autentifică-te în Portal
Utilizatorii Portalului se autentifică cu email și parolă și primesc o pereche de jetoane:
- Un jeton de acces valabil 15 minute, trimis la fiecare apel API ca
Authorization: Bearer <jeton>. - Un jeton de reîmprospătare valabil 7 zile, folosit doar pentru a obține un nou jeton de acces.
Parcurge fluxul de autentificare
Autentifică-te
POST /api/v1/auth/login
Content-Type: application/json
{ "email": "tu@exemplu.ro", "password": "…" }
Răspunsul conține accessToken, refreshToken și profilul utilizatorului.
Apelează endpoint-uri protejate
Trimite jetonul de acces la fiecare cerere:
GET /api/v1/devices
Authorization: Bearer <accessToken>
Reîmprospătează înainte de expirare
Când jetonul de acces expiră (sau mai devreme — oricând în fereastra de 7 zile a reîmprospătării), schimbă jetonul de reîmprospătare pe o pereche nouă:
POST /api/v1/auth/refresh
Content-Type: application/json
{ "refreshToken": "<refreshToken>" }
Jetonul de reîmprospătare anterior este invalidat imediat. Înlocuiește ambele jetoane stocate cu perechea nouă din răspuns.
Deconectează-te
POST /api/v1/auth/logout
Authorization: Bearer <accessToken>
Content-Type: application/json
{ "refreshToken": "<refreshToken>" }
Asta revocă doar jetonul de reîmprospătare furnizat. Sesiunile de pe alte dispozitive rămân active.
401 — Refresh token has been revoked. Utilizatorul trebuie să se autentifice din nou.Pentru forma completă a cererilor și răspunsurilor, vezi Referința API-ului de autentificare.
Gestionează permisiunile cheii API
Fiecare cheie API poartă una sau mai multe permisiuni. Fiecare cerere are nevoie de o permisiune anume; dacă lipsește din cheie, API-ul returnează 403 FORBIDDEN — Insufficient scopes.
| Permisiune | Folosește-o pentru |
|---|---|
receipts | Creare și citire de bonuri fiscale. |
receipts:read | Acces doar pentru citire la bonuri (rapoarte, exporturi). |
receipts:admin | Acțiuni de bon de nivel admin (anulare / stornare). |
reports | Generare și citire de rapoarte X, Z, raport zilnic și raport lunar. |
devices | Acces general la dispozitive (listare, citire, actualizare). |
devices:read | Listare și citire de dispozitive doar pentru citire. |
devices:write | Creare, actualizare sau ștergere de dispozitive; atribuire de operatori; configurare fiscală. |
commands | Emitere de comenzi pe dispozitiv (POST /devices/:id/commands). |
all | Acces universal — satisface orice verificare de permisiune. |
receipts; un dashboard de raportare are nevoie doar de receipts:read și reports.Gestionează rolurile utilizatorilor
Utilizatorii Portalului au unul dintre trei roluri, setat când sunt adăugați în organizație:
| Rol | Ce poate face |
|---|---|
owner | Acces complet la Portal. Creat automat pentru utilizatorul care înregistrează organizația. Poate șterge organizația. |
admin | Același acces la Portal ca Owner, cu excepția acțiunilor de ștergere a organizației. |
operator | Utilizare zilnică a Portalului — vizualizare bonuri, rulare rapoarte, gestionare operatori pe dispozitive. Suprafață administrativă redusă. |
Rolurile sunt evaluate la fiecare apel către API-ul Portalului. Dacă un utilizator încearcă o acțiune pe care rolul lui nu o permite, API-ul returnează 403 FORBIDDEN — Insufficient role.
Înțelege limitele de plan
Unele acțiuni sunt limitate de planul tău de abonament:
| Plan | Dispozitive maxime | Chei API permise |
|---|---|---|
| Free | 2 | Nu |
| Pro | 10 | Da |
| Enterprise | Nelimitat | Da |
Când atingi o limită de plan, API-ul returnează 403 TIER_LIMIT_EXCEEDED cu un mesaj care îți spune ce limită ai atins și cum o ridici (de obicei: upgrade de plan).
Tratează limitele de rată
API-ul aplică trei plicuri de limitare a ratei. Toate trei returnează același răspuns la epuizare:
{
"code": "RATE_LIMIT_EXCEEDED",
"message": "Too many requests, please try again later.",
"status": 429
}
Fiecare răspuns 429 include un antet Retry-After în secunde — așteaptă cel puțin atât înainte de a reîncerca.
| Plic | Fereastră | Limită | Se aplică la | Indexat după |
|---|---|---|---|---|
| Global | 10 min | 150 cereri | Fiecare cerere către API | Prefix de cheie API dacă există, altfel IP-ul |
| Autentificare | 10 min | 30 cereri | POST /auth/register, /auth/login, /auth/refresh, /auth/forgot-password | IP-ul clientului |
| Comenzi pe dispozitiv | 10 min | 50 cereri | POST /devices/:deviceId/commands și endpoint-urile wrapper | Prefix de cheie API dacă există, altfel IP-ul |
429, respectând antetul Retry-After.Tratează erorile de autentificare {#trateaza-erorile-de-autentificare}
Fiecare eșec de autentificare și autorizare returnează un plic JSON structurat cu un câmp code stabil. Folosește code (nu mesajul în limbaj natural) când construiești tratarea de erori.
| HTTP | code | Mesaj | Ce înseamnă |
|---|---|---|---|
| 401 | UNAUTHORIZED | Missing or invalid Authorization header. Expected: Bearer <token> | Ai uitat antetul Authorization sau l-ai trimis în format greșit. |
| 401 | UNAUTHORIZED | Missing access token | Antetul există, dar jetonul de după Bearer este gol. |
| 401 | UNAUTHORIZED | Invalid or expired access token | Jetonul de acces din Portal este invalid, expirat sau semnat de altcineva. Reîmprospătează-l. |
| 401 | UNAUTHORIZED | Refresh token has been revoked | Jetonul de reîmprospătare a fost deja folosit sau a fost revocat. Autentifică-te din nou. |
| 401 | UNAUTHORIZED | Invalid or expired refresh token | Jetonul de reîmprospătare este malformat sau a depășit fereastra de 7 zile. Autentifică-te din nou. |
| 401 | UNAUTHORIZED | Missing API key. Provide via x-api-key header or Authorization: Bearer <key>. | Niciun credențial pe un endpoint protejat. |
| 401 | UNAUTHORIZED | Invalid API key format. | Cheia nu se potrivește cu ebon_live_{orgId}_{32-hex}. Probabil este trunchiată sau copiată greșit. |
| 401 | UNAUTHORIZED | Invalid API key. | Cheia are forma corectă, dar nu este înregistrată pentru această organizație. |
| 401 | UNAUTHORIZED | API key is inactive. | Cheia a fost revocată din Portal. Creează una nouă. |
| 401 | UNAUTHORIZED | Missing authentication. Provide an API key via x-api-key header or a JWT via Authorization: Bearer <token>. | Endpoint-ul acceptă oricare credențial și nu ai trimis niciunul. |
| 403 | FORBIDDEN | Insufficient role. Required: <rol> or <rol> | Utilizatorul autentificat nu are un rol permis pentru acest endpoint. |
| 403 | FORBIDDEN | Insufficient scopes. Missing: <scope>, <scope> | Cheia API este valabilă, dar îi lipsesc permisiunile cerute de acest endpoint. |
| 403 | TIER_LIMIT_EXCEEDED | Device limit reached. Your <plan> plan allows a maximum of <N> devices (current: <K>). Upgrade your plan to add more devices. | Ai atins plafonul de dispozitive al planului. |
| 403 | TIER_LIMIT_EXCEEDED | API keys are not available on the Free plan. Upgrade to Pro to create API keys. | Planul Free nu poate crea chei API. |
| 429 | RATE_LIMIT_EXCEEDED | Too many requests, please try again later. | Ai atins un plic de limită. Așteaptă cel puțin Retry-After secunde. |
401nu disting o semnătură proastă de un jeton expirat sau de unul malformat — toate returnează Invalid or expired access token. Tratează orice 401 UNAUTHORIZED pe un endpoint protejat ca „credențialul este mort, obține unul nou", nu ca un diagnostic care poate fi parsat.Unde mergi mai departe
- Referința API-ului de autentificare — formele complete ale cererilor și răspunsurilor pentru
/auth/{register,login,refresh,logout,forgot-password}. - Referința API-ului de chei API — referința REST pentru gestionarea cheilor programatic.
- Portal: Chei API — fluxul de UI pentru creare, atribuire de permisiuni și revocare a cheilor.
- Portal: Înregistrare — fluxul de bootstrap pentru primul Owner și pentru organizație.
- Ghidul de integrare — bucla sandbox cap-coadă care exercită împreună autentificarea, bonurile fiscale și webhook-urile.
Cum funcționează emiterea bonului fiscal
Înțelege cum trimite e-bon o comandă de tipărire către dispozitiv, când comută pe trezirea prin push, cât durează fiecare etapă și cum primești rezultatul final.
Notificări email
Ce emailuri automate trimite e-bon astăzi, ce conține emailul cu raportul Z de sfârșit de zi, cum alegi cine îl primește și ce să faci dacă un destinatar nu primește mesajul.