Avito Products Laravel Package

Product Decisions This Supports

• Marketplace channel expansion (RU): Enables publishing and synchronizing product listings to Avito, Russia's largest classifieds marketplace. This is the primary decision the package informs: whether Avito becomes a supported sales channel in the roadmap.
• Build vs. buy for marketplace integration: Provides a reference implementation of Avito product/listing operations (fetch, filter by region/price, pagination, bulk/batch reads, webhook handling). This lets us scope the "buy" option before committing engineering to a custom client.
• Integration architecture: If adopted, it pushes us toward an adapter boundary — our domain models should not depend directly on a third-party Avito client, so a later swap to a thin in-house HTTP client stays cheap.
• Data model decisions: Category/taxonomy mapping, region and price filtering, and product-ID linkage between our catalog and Avito listings.
• Roadmap sequencing: Informs prioritization of Avito against other channels (Ozon, Wildberries, Yandex Market). Unlike a generic e-commerce library, this is single-marketplace scope, so it only justifies investment when Avito is a named target.
• Not supported: general product catalog management, multi-marketplace abstraction, or anything outside the Avito domain.

When to Consider This Package

Consider it when:

• Avito is a confirmed or strongly suspected revenue channel and you need listing/product management, not just a one-off API read.
• You are already on the baks-dev ecosystem (baks-dev/core ^7.4) or an equivalent Symfony-style stack — the integration cost drops sharply and the module is designed to compose with its siblings.
• You are on PHP 8.4+ and can absorb integration uncertainty: thin documentation (Russian-language README), no usage examples in the repo, zero dependents.
• You want to move fast on a low-stakes pilot. MIT license means we can fork and patch without negotiation.
• You need webhook ingestion, batching, and filter parameters — features that would otherwise be hand-rolled.

Look elsewhere when:

• The application is Laravel-first. This is not a Laravel-native package: there is no documented service provider, no Eloquent integration, and a hard dependency on a Symfony-oriented core. Bridging it into Laravel's container is real, unbudgeted work.
• You only need simple, read-only API calls. Avito's public REST API plus Laravel's Http client covers that in a fraction of the dependency surface.
• You require vendor support, an SLA, or evidence of production usage. One star, zero dependents, and release notes that consist solely of version numbers are all we have to go on.
• You need multi-marketplace abstraction. This is Avito-specific; adopting it as a "marketplace layer" would be a misread.
• Your market is outside Russia. Domain value is effectively zero.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed, single-purpose module for selling through Avito. The cost of trying it is low; the cost of committing to it blind is moderate, because it belongs to a wider baks-dev ecosystem rather than being a standalone Laravel package, and it has no community, no dependents, and no meaningful documentation beyond installation. My recommendation is a time-boxed spike (one to two sprints) to confirm that its Avito API coverage matches what we actually sell, and that it can be wired into our framework without a bespoke bridge. Do not put Avito on the roadmap on the strength of this package alone. The good news is the downside is capped: the Avito API surface we need is narrow, so a fallback in-house client is a small, well-understood build.

For engineering: Treat it as a reference implementation and a possible accelerator, not a foundation. PHP 8.4+, dependency on baks-dev/core, Symfony-style conventions — expect adapter work if we are Laravel-native. Wrap it behind our own AvitoProductClient interface from day one so replacement is a swap, not a refactor. Assume we own maintenance: pin versions, watch upstream breaking changes, and be prepared to fork given the MIT license and the maintainer's single-person footprint. Validate webhook signature handling and rate-limit behavior early — those are the two places where a thin wrapper most often turns into an incident.