Portal pentru dezvoltatori

Acest ghid acoperă autorizarea OAuth și token-urile folosite de Application. Pentru cine este Partner, Application (Client) și User, consultați Partner, aplicație și utilizator.

Flux de autorizare

Când Application trebuie să acționeze în numele unui User, User trebuie să acorde acces prin OAuth:

sequenceDiagram
    actor User
    participant App as Application
    participant OLX as OLX
    App->>User: 1. Afișează linkul de autentificare OLX
(/oauth/authorize)
    User->>OLX: 2. Deschide linkul în browser, se autentifică
și acceptă Application
    OLX->>User: 3. Redirecționare browser cu authorization_code
    User->>App: 4. Browserul urmează redirect_uri
cu authorization_code
    App->>OLX: 5. Schimbă authorization_code pentru token-uri
(grant_type: authorization_code)
    OLX->>App: access_token, refresh_token
    Note over App: Stochează token-urile doar pentru acest User.
User nu le vede.

Operațiuni

După autorizare, User lucrează doar cu Application. Application apelează API OLX cu access_token stocat. User nu trimite și nu primește niciodată acel token:

sequenceDiagram
    actor User
    participant App as Application
    participant API as OLX API
    User->>App: 1. Inițiază o acțiune
(fără access_token OLX)
    Note right of User: ex. publică această ofertă pe OLX
    App->>API: 2. Cerere API cu access_token
ex. POST /adverts
    Note over App,API: access_token folosit aici
(doar Application ↔ API OLX)
Tokenul rămâne în Application
User nu îl trimite sau primește
    API->>App: 3. Răspuns API
succes / eroare
    App->>User: 4. Afișează rezultatul Userului
(fără access_token OLX)

Token-uri folosite de Application

În procesul de autorizare apar următoarele elemente:

Context User — token în contextul unui User specific

Folosit când Application acționează în numele unui User (vânzător / lister).

• authorization_code — cod unic pe care Application îl primește după ce User acordă acces la contul OLX. Application schimbă acest cod pentru un access_token și un refresh_token.
• access_token — token pe care Application îl trimite cu cererile API în numele acelui User. Are durată de viață limitată (vezi expires_in în răspunsul token). Când expiră, Application folosește refresh_token pentru un access_token nou. Cu access_token de User, Application poate publica anunțuri, citi statusuri, primi mesaje și efectua alte acțiuni în scope-ul utilizatorului. Un token pentru User John Doe nu poate fi folosit pentru User Jane Humbug — inventarul fiecărui User rămâne separat.
• refresh_token — token folosit în contextul User pentru a obține un access_token nou după expirarea celui anterior. Trăiește mai mult decât access token-ul. Poate fi folosit până la expirare sau invalidare. Fluxul de refresh poate returna un refresh_token nou — stocați-l și folosiți pe cel mai recent. Dacă refresh_token expiră sau devine invalid, User trebuie să treacă din nou prin autorizare pentru un authorization_code nou, apoi access_token și refresh_token noi.

Context Client — token în contextul Application

Obținut cu grant type client_credentials. Aceste token-uri nu au context de User. Sunt folosite pentru operațiuni care nu necesită date de User — de exemplu categorii, locații și alte date partajate între Users.

• access_token — token pe care Application îl trimite cu cererile API în contextul Application (Client). Are și el durată limitată; la expirare, Application solicită unul nou cu client_id / client_secret și grant_type: client_credentials. Nu există refresh_token în acest flux. Acest token nu poate acționa în numele unui User — doar accesează resurse partajate.
• client_id / client_secret — credențiale Application din Developer Portal. Împreună cu grant_type: client_credentials sunt folosite pentru a obține un token în context Client. (client_credentials este numele grant type, nu secretul în sine.)

Pentru detalii despre cereri, endpoint-uri și scope-uri, consultați secțiunea Authentication din documentația API.

Pentru a vă înregistra ca Partner și a crea o Application, urmați Obținerea accesului la API.