Yandex Market Laravel Package

Product Decisions This Supports

• Channel-expansion go/no-go for Yandex.Market. If adding a Russian marketplace is on the roadmap, this package is the lowest-cost way to test the hypothesis. It removes "we'd have to build the API client first" from the debate, turning a 1–2 quarter greenfield build into a time-boxed spike.
• Build vs. buy-and-fork for marketplace adapters. Frame the choice honestly: not "adopt a supported vendor library" but "adopt MIT-licensed scaffolding we fork and own." The buy side of the ledger is real (auth, endpoints, retry/backoff logic on day one), but so is the ownership tax (0.1–0.2 FTE/yr).
• Async infrastructure investment. The package is queue-first: per-token Messenger transports with configurable maxRetries, delay, and multiplier. Adopting it implicitly commits you to durable workers, dead-letter handling, and queue observability for marketplace syncs. That's a platform decision, not a package detail — decide it deliberately.
• Seller-onboarding topology. The one genuinely differentiated feature is per-credential queue isolation, which maps to "one queue/supervisor per seller token." That supports a product decision about whether you onboard many sellers with independent credentials (where isolation matters) versus one master account (where it doesn't).
• Feature sequencing. The retry-tolerant, async design points toward bulk catalog upload and price sync first, and away from real-time order status. Use it to order the backlog: tolerant batch jobs before latency-sensitive events.
• Multi-marketplace strategy. If Yandex.Market is one of 3–5 target platforms, patterns from this package (credential storage, retry policy, queue naming) can seed a shared adapter layer. If it's the only one, that reuse argument evaporates and the build-vs-buy math shifts toward "write a thin client ourselves."
• Dependency-quality bar. Adopting a 0-star, 0-dependent, single-maintainer package is itself a policy decision. Good forcing function for defining the minimum bar for third-party dependencies and the security-review path for a fork.

When to Consider This Package

Consider it when:

• Yandex.Market is a near-term revenue or seller-acquisition target, not a someday item.
• Your stack is PHP 8.4+ (which implies Laravel 11+) and you already run, or are willing to run, background workers with retries and a dead-letter queue.
• You need per-seller isolation — many tokens, many queues, independent retry strategies. This is the package's clearest edge over rolling your own.
• Your primary workload is bulk/batch (catalog sync, price updates) where eventual consistency is acceptable.
• You're comfortable treating it as a foundation to fork, with your team owning onboarding, docs, and upgrades.

Look elsewhere when:

• You need real-time order or inventory events. There is no webhook handling; Yandex's native webhooks must be integrated separately, which erodes the "saves us integration work" pitch.
• Your backend is Node, Python, Go, or non-Laravel PHP. Caveat worth flagging to stakeholders: despite being pitched as a "Laravel/PHP package," every artifact here is Symfony-shaped — bin/console, Messenger transports, a baks:* namespace implying a shared framework core. Verify Laravel fit in a spike before planning around it; budget an extra sprint if the Symfony-first reality forces a queue bridge.
• You're on PHP < 8.4 or Laravel < 10 and can't upgrade this cycle — treat that as an infrastructure prerequisite, not a package task.
• You require vendor SLAs, security artifacts, or a support contract. There is none.
• Yandex.Market is expected to be <10% of revenue — fixed ownership cost likely exceeds payoff.
• You need analytics, dashboards, or a seller portal. This is a transport layer, not a product surface.
• Provenance matters and you can't verify it: single maintainer, no community, release notes that are literally the version string, and a release dated 2026-06-01 worth sanity-checking before adoption.

How to Pitch It (Stakeholders)

One-line framing: An MIT-licensed PHP integration for the Yandex.Market API that lets us test the Russian marketplace channel in weeks rather than quarters — provided we accept ownership of the code.

For executives:

• The decision: fund a 6–8 week pilot (starting with a 2-week technical spike) to list and sync a small cohort of sellers on Yandex.Market.
• Why this way: the alternative is 1–2 quarters of custom API work with no revenue signal until the end. This package covers authentication, endpoint plumbing, and retry handling on day one, for free under MIT.
• The honest caveat: it is a small, unmaintained-looking project — no community, no support, sparse docs (Russian-only README, version-string release notes). Treat it as open-source scaffolding we fork and harden, not a vendor product. That shifts cost from "license fee" to "roughly two sprints of engineering plus ongoing ownership" — still far cheaper than greenfield.
• Success metrics: sellers onboarded, listings live, order-sync error rate, time-to-first-listing.
• Kill criteria — make them explicit: e.g., stop if the technical spike shows the package drags in a required framework core we can't isolate, or if integration effort exceeds X engineer-weeks.
• Risk: concentrated in maintainability and the async-only design (no webhooks, so real-time order status is a second integration surface). Both are bounded if we pilot before committing.

For engineering:

• Verify the stack assumption first. Despite being described as a Laravel package, the install flow (bin/console baks:assets:install), Messenger transports, and retry configuration are all Symfony idioms. Confirm it boots under a Laravel 11 service provider and that its queues work with Horizon before we plan around it.
• Resolve the transitive dependency question. The baks:assets:install command implies a shared baks-dev framework layer. If that's a required dependency, we're adopting a framework, not an API client — that's the single highest-leverage unknown and needs a hard go/no-go gate.
• Keep the good part: per-token queue transports with configurable retries, delays, and backoff multipliers. Map these onto Horizon supervisors per seller token for credential isolation.
• Enforce a boundary: wrap the package behind our own MarketplaceClient / CatalogSync / OrderFeed interfaces. Nothing in our controllers or jobs imports package namespaces directly — that's what makes a zero-star dependency defensible and a later swap cheap.
• Own the data and secrets: store credentials in our encrypted config or secrets manager, not in whatever storage the package defaults to until that mechanism is documented.
• Known gaps to plan for: no webhook support (Yandex's native webhooks must land in our own controller), and thin test coverage beyond a --group=yandex-market flag — write contract tests against the sandbox.
• Recommended next step: a 2-week spike — install in a clean Laravel 11 app, publish config, run one read-only API call per token, confirm queue dispatch and retries work in our environment, and enumerate which endpoint families are actually covered. Succeed and we wrap it; fail and we've spent two weeks, not two quarters.