Developer Portal

This guide covers OAuth authorization and tokens used by the Application. For who is a Partner, Application (Client), and User, see Partner, Application, and User.

Authorization flow

When the Application needs to act on behalf of a User, the User must grant access via OAuth:

sequenceDiagram
    actor User
    participant App as Application
    participant OLX as OLX
    App->>User: 1. Shows the OLX auth link
(/oauth/authorize)
    User->>OLX: 2. Opens link in browser, logs in
and accepts the Application
    OLX->>User: 3. Browser redirect with authorization_code
    User->>App: 4. Browser follows redirect_uri
with authorization_code
    App->>OLX: 5. Exchanges authorization_code for tokens
(grant_type: authorization_code)
    OLX->>App: access_token, refresh_token
    Note over App: Stores tokens for this User only.
User never sees them.

Operations

After authorization, the User works only with the Application. The Application calls the OLX API with the stored access_token. The User never sends or receives that token:

sequenceDiagram
    actor User
    participant App as Application
    participant API as OLX API
    User->>App: 1. Initiates an action
(no OLX access_token)
    Note right of User: e.g. publish this offer on OLX
    App->>API: 2. API request with access_token
e.g. POST /adverts
    Note over App,API: access_token used here
(Application ↔ OLX API only)
Token stays on the Application
User never sends or receives it
    API->>App: 3. API response
success / error payload
    App->>User: 4. Shows the result to the User
(no OLX access_token)

Tokens the Application uses

In the authorization process the following items appear:

User context — token with a specific User's context

Used when the Application acts on behalf of a User (seller / lister).

• authorization_code — one-time code the Application receives after the User grants access to their OLX account. The Application exchanges this code for an access_token and a refresh_token.
• access_token — token the Application sends with API requests on behalf of that User. It has a limited lifetime (see expires_in in the token response). When it expires, the Application uses the refresh_token to get a new access_token. With a User access_token the Application can publish ads, read statuses, receive messages, and perform other user-scoped actions. A token for User John Doe cannot be used for User Jane Humbug, so each User's inventory stays separate.
• refresh_token — token used in the User context to obtain a new access_token after the previous one expires. It lives longer than the access token. It can be used until it expires or is invalidated. The refresh flow may also return a new refresh_token — store it and use the latest one. If the refresh_token expires or is no longer valid, the User must go through authorization again to get a new authorization_code, and then a new access_token and refresh_token.

Client context — token with the Application's context

Obtained with grant type client_credentials. These tokens have no User context. They are used for operations that do not need a User's data — for example categories, locations, and other data shared across Users.

• access_token — token the Application sends with API requests in the Application (Client) context. It also has a limited lifetime; when it expires, the Application requests a new one with client_id / client_secret and grant_type: client_credentials. There is no refresh_token in this flow. This token cannot perform actions on behalf of a User — only access shared resources.
• client_id / client_secret — Application credentials from the Developer Portal. Together with grant_type: client_credentials they are used to obtain a Client-context token. (client_credentials is the grant type name, not the secret itself.)

For request details, endpoints, and scopes, see the Authentication section in the API documentation.

To register as a Partner and create an Application, follow Getting access to API.