Getting Started

Reality check before install

Despite being described as "Laravel/PHP," baks-dev/four-tochki-products is a Symfony bundle. Every installation step in the README assumes a Symfony app: bin/console, baks:assets:install, Doctrine migrations, PHPUnit test groups. There is no php artisan, no config/*.php publish tag, no Eloquent model, and no service provider. Treat this as a Symfony component you consume from Laravel, not a Laravel package you composer require and move on.

Minimal steps

Confirm toolchain: PHP 8.4+ (this forces Laravel 11/12 if you are on the Laravel side), plus a Symfony app skeleton to host the bundle.
composer require baks-dev/four-tochki-products
Register the bundle in the Symfony host's config/bundles.php (the README omits this — check the bundle for its *Bundle class name).
php bin/console baks:assets:install — installs config + file resources into the Symfony app.
php bin/console doctrine:migrations:diff && php bin/console doctrine:migrations:migrate — generates and runs the schema (products, warehouses, inventory).
Run the package's own test suite once to sanity-check: php bin/phpunit --group=four-tochki-products

Where to look first

src/: the bundle has no documented services, so the Entity and Service/Repository folders are your only source of truth for what the package can actually do. Read Entity/* to learn the schema before touching migrations.
config/: after baks:assets:install, this is where the package's configuration lands. This is where API credentials and warehouse IDs will go.
https://b2b.4tochki.ru/Account/AvailableWarehouses: the only documented external dependency — you must know your partner warehouse IDs before any sync makes sense.
resources/ / templates/: assets installed by the console command.

First use case

The realistic first use case is product catalog mirroring: pull the 4tochki product/warehouse data into your app's schema, then expose it to Laravel. Because the bundle's schema is Doctrine-managed, the shortest path is:

Install the bundle into a throwaway Symfony app.
Run doctrine:migrations:diff and capture the generated SQL.
Re-author that SQL as Laravel migrations in your real app.
Consume the tables from Laravel Eloquent models you write yourself.

This is slower than composer require implies, but it is the only pattern that keeps the ORM worlds separated while still being honest about where the data comes from.

Implementation Patterns

Pattern 1: Sidecar Symfony service (recommended)

Do not mix Doctrine and Eloquent in one process. The bundle assumes Doctrine's EntityManager, Symfony's console, and its own config loader; dropping it into a Laravel app will fight the framework at every boot.

Run the bundle in a tiny Symfony container (or the Symfony CLI dev server) as a companion service.
Expose the operations you actually need — list warehouses, fetch product, upsert SKU — via a thin HTTP layer (a couple of controller actions you write).
Laravel talks to that sidecar with Http::withToken(...). You keep Laravel on Eloquent and leave Doctrine to the sidecar.

This matches the "Symfony micro-service in Docker" approach the product team already flagged as the safe path.

Pattern 2: Schema extraction into Laravel

If you must keep a single app:

Use the bundle's doctrine:migrations:diff output as a reference, not as a runtime dependency.
Rewrite those migrations as Laravel Schema::create(...) files in database/migrations.
Write Eloquent models (FourTochkiProduct, FourTochkiWarehouse, FourTochkiStock) that mirror the Doctrine entities 1:1.
Keep the bundle installed only in a tools/ Composer workspace so it never enters your production autoloader.

Pattern 3: Warehouse-routed inventory sync

4tochki is warehouse-centric (that is the whole point of the AvailableWarehouses link). Structure your sync around warehouses, not SKUs:

One row per (sku, warehouse_id) for stock levels.
A job per warehouse rather than per product, so a single failed warehouse does not stall the catalog.
Schedule via Laravel's Schedule::command('fourtochki:stock')->hourly() on the Laravel side, calling the sidecar.

Pattern 4: Async, idempotent writes

Catalog and stock updates are the kind of thing that will be retried. Make every write upsert on SKU, and wrap network calls in a queued job with exponential backoff. The package does not advertise a queue integration, so assume none exists and build one.

Integration tips

Bind the bundle's services via the Symfony container in the sidecar, and expose them behind your own DTOs so your Laravel code has no knowledge of Baks\ namespace classes.
Keep a sync_state column on your Eloquent models (pending, synced, failed, last_error) — you will need it for debugging because the README documents no error-handling surface.
Log the raw API payloads on failure. With Russian-only docs and no documented error classes, the payload is the only reliable debugging signal.

Gotchas and Tips

It is not a Laravel package — no exceptions

php artisan baks:assets:install will not work. The command is Symfony Console. Use php bin/console baks:assets:install inside the Symfony host.
php artisan test --group=four-tochki-products will not work. That flag belongs to PHPUnit; run php bin/phpunit --group=four-tochki-products in the Symfony host.
php artisan migrate will not pick up the bundle's migrations. They are Doctrine migrations, run via doctrine:migrations:migrate.
Any blog post or generated assessment showing ProductSyncService::syncProduct(...) as a Laravel call is invented — the README does not expose such a class. Verify class names in src/ before writing code against them.

PHP 8.4 floor

PHP 8.4 minimum means you are pinned to Laravel 11.x/12.x era runtimes. If you are on Laravel 10 or older, either upgrade or keep the bundle strictly in the sidecar. Do not try to downgrade the package.

Doctrine vs Eloquent schema conflicts

The bundle will generate tables with names it controls (product, warehouse, or similar). These will collide with your existing Laravel products table if you share a database. Use a dedicated schema / prefix (four_tochki_*) or, better, separate databases entirely.

Documentation gaps

README is Russian only and contains only install steps — there is no usage documentation, no API reference, no service list.
0 stars, 0 dependents, and the "last release" date (2026-06-05) is unusual for a package you would adopt today. Treat the release cadence as unreliable for planning.
No visible changelog per version (## v7.4.12 is literally the whole release note). You cannot infer breaking changes from version numbers.

Debugging

Confirm the bundle registered by checking config/bundles.php in the Symfony host and by running php bin/console debug:container | grep -i tochki.
Confirm assets installed by listing the target directories after baks:assets:install; if the command silently succeeds with nothing written, you are likely missing the bundle registration.
If doctrine:migrations:diff produces an empty diff, your Entity mapping is not being scanned — check doctrine.orm.mappings in the Symfony config/packages/doctrine.yaml.

Extension points

There are no documented extension points. Anything you need beyond what src/ provides means forking: add your own Symfony services that wrap the bundle's repositories, and expose them over your sidecar controller. Budget for this — do not assume the package will grow to meet your needs.

When to walk away

If your requirement is anything beyond pulling catalog/warehouse data into a schema you control, and your team is a pure Laravel team, the honest comparison is Guzzle against the 4tochki B2B API directly. The package saves you the reverse-engineering of an undocumented API; it does not save you the integration work.

Four Tochki Products Laravel Package