README

This package implements PHP client for OLX Partner API.

Requirements

PHP 7.4 or newer — CI runs the suite on 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5
Guzzle 7 or 8 — either works, and both are covered by CI
ext-json

Installation

To install the package to your project via Composer simply run:

composer require matasarei/olx-api-client-v2

Documentation

Official OLX API documentation and developers portal:

Check the troubleshooting section if you have any issues.

Usage

Basic Example

use Gentor\Olx\Api\Client;
use Gentor\Olx\Api\Credentials;

$credentials = new Credentials('your_client_id', 'your_client_secret');
$client = new Client($credentials, Client::OLX_UA);

// Create an advert
$response = $client->adverts()->create([
    'title' => 'My Product',
    'description' => 'Product description...',
    'category_id' => 123,
    // ... other required fields
]);

// Access the created advert data
$advertData = $response['data'];
echo "Created advert ID: " . $advertData['id'];
echo "Status: " . $advertData['status'];

Important: API Response Format

All OLX API responses wrap the actual data in a data key according to the official API specification:

// What you get from the API:
[
  'data' => [
    'id' => 905890605,
    'status' => 'active',
    // ... other advert fields
  ]
]

// Access the actual data:
$response = $client->adverts()->create($request);
$advertData = $response['data'];

This response format applies to advert-related endpoints, for example:

GET /adverts returns ['data' => [array of adverts]]
POST /adverts returns ['data' => {advert object}]
GET /adverts/{id} returns ['data' => {advert object}]
PUT /adverts/{id} returns ['data' => {advert object}]

Other endpoints may have different response structures. Please refer to the official OLX API documentation for details on the response format of each endpoint.

Testing and development

The commands below run through Docker, so no local PHP install is needed.

Use the composer:2 image rather than composer:lts. The LTS image ships Composer 2.2, which predates security-advisory checking — it installs dependencies with known vulnerabilities without saying a word, which is how #9 went unnoticed locally while consumers could not install the package at all.

Install vendors

docker run --rm -v $(pwd):/app -w /app composer:2 composer update

Run tests

docker run --rm -v $(pwd):/app -w /app composer:2 vendor/bin/phpunit

Check for vulnerable dependencies

docker run --rm -v $(pwd):/app -w /app composer:2 composer audit --no-dev

Reproducing the CI dependency matrix

composer update on its own only ever resolves the newest allowed versions, which for ^7.4 || ^8.0 always means Guzzle 8. CI additionally proves the floor of every constraint and the Guzzle 7 path, and you can run either locally:

# Floor of every constraint (currently Guzzle 7.15.1 + psr7 2.13.0)
docker run --rm -v $(pwd):/app -w /app composer:2 composer update --prefer-lowest --prefer-stable

# The Guzzle 7 half of the constraint
docker run --rm -v $(pwd):/app -w /app composer:2 \
  composer update --with "guzzlehttp/guzzle:^7.15" --with "guzzlehttp/psr7:^2.13"

Note that composer update is used throughout rather than composer install: only re-resolving applies Composer's security-advisory policy, so a dependency that has gone vulnerable fails loudly instead of silently installing.

Testing against a specific PHP version

Dependencies have to be resolved for the target version, otherwise Composer picks packages requiring a newer PHP and the suite dies on a syntax error rather than a real failure. Pin the platform, run the suite, then restore composer.json:

docker run --rm -v $(pwd):/app -w /app composer:2 composer config platform.php 7.4.33
docker run --rm -v $(pwd):/app -w /app composer:2 composer update
docker run --rm -v $(pwd):/app -w /app php:7.4-cli php vendor/bin/phpunit
git checkout composer.json   # drops the temporary platform pin

matasarei / olx-api-client-v2

Maintainers

Package info

Statistics

Security