Automatic Supplier Stock Sync on Laravel

A customer adds an item to cart, places an order, and an hour later the manager says: "This item is out of stock." Or the opposite: the item is available but hidden due to zero stock in an outdated feed. According to statistics, up to 30% of orders are canceled precisely due to incorrect stock data, and managers spend up to 2 hours daily manually reconciling CSV files. This is a typical situation with manual stock sync.

We solve it with automatic stock data sync from suppliers. Our engineers have 6+ years of experience in integrations — from 1C to marketplaces. After implementation, you'll forget manual sync. Integration budget of $2,000–$5,000 is typically offset within 3–6 months through reduced labor and fewer cancellations. After implementation, one client saved $2,000/month in operational costs, and another reduced order cancellations from 15% to 2%. Data accuracy improved from 60% to 99% after sync automation. Supplier stock sync is an investment that pays off through increased stock accuracy and conversion.

Our automatic stock updates for supplier stock sync leverage Laravel upsert for bulk upsert stocks. Multi-warehouse sync with warehouse aggregation ensures accurate stock across all locations. Webhook stock updates provide real-time data, while delta stock updates are efficient for moderate frequency. Our PHP CSV import parser handles any format, and product visibility management automatically updates the storefront after each sync.

Which data needs to be synced?

A complete stock picture includes:

• qty — quantity of units at the supplier's warehouse
• warehouse — which warehouse (especially important for regional warehouses)
• available_date — expected arrival date if currently 0
• reserved — reserved for other orders
• status — discontinued, made-to-order, wholesale only

Minimal set for most stores: sku, qty, warehouse_id.

Automatic Stock Sync Methods

CSV/Excel on schedule

The most common option — the supplier places an updated file on FTP every hour. We implement StockSourceInterface and a parser for the specific format:

class FtpStockSource implements StockSourceInterface { public function fetch(): array { $ftp = ftp_connect($this->host); ftp_login($ftp, $this->user, $this->pass); $tmpFile = tempnam(sys_get_temp_dir(), 'stock_'); ftp_get($ftp, $tmpFile, $this->remotePath, FTP_BINARY); ftp_close($ftp); $reader = \PhpOffice\PhpSpreadsheet\IOFactory::load($tmpFile); $rows = $reader->getActiveSheet()->toArray(); unlink($tmpFile); $stocks = []; foreach (array_slice($rows, 1) as $row) { // skip header $stocks[] = [ 'sku' => (string) $row[0], 'qty' => (int) $row[2], ]; } return $stocks; } } 

REST API with delta updates

Modern suppliers provide an endpoint for incremental changes. We request only those SKUs whose stock changed since the last poll. This saves traffic and processing time.

Webhook from supplier

If the supplier can push changes, we accept a POST request and queue a job. The endpoint responds in <200 ms. Webhook is the most prompt method.

class StockWebhookController { public function __invoke(Request $request, string $source): JsonResponse { $payload = $request->validated(); ProcessStockWebhookJob::dispatch($source, $payload); return response()->json(['status' => 'queued']); } } 

Data Processing and Aggregation

Method comparison

Warehouse aggregation

The final stock on the site is the sum across all active warehouses or based on priority. For example, the "Moscow" warehouse is primary: if it has qty > 0, show it; otherwise show others. We implement this via a view or computed field. Example SQL view:

CREATE VIEW product_available_stock AS SELECT product_id, SUM(qty) AS total_qty, MAX(updated_at) AS last_synced_at FROM product_stocks WHERE source_active = true GROUP BY product_id; 

Bulk upsert

We use upsert for mass updates — one query for 500 rows instead of N individual UPDATEs. Laravel upsert works via INSERT ... ON CONFLICT DO UPDATE in PostgreSQL.

class StockUpdater { public function apply(array $stocks, int $sourceId): StockUpdateResult { $updated = $skipped = 0; $chunks = array_chunk($stocks, 500); foreach ($chunks as $chunk) { $rows = []; foreach ($chunk as $item) { $productId = $this->skuMap[$item['sku']] ?? null; if (!$productId) { $skipped++; continue; } $rows[] = [ 'product_id' => $productId, 'source_id' => $sourceId, 'qty' => max(0, $item['qty']), 'updated_at' => now(), ]; $updated++; } if ($rows) { DB::table('product_stocks')->upsert( $rows, ['product_id', 'source_id'], ['qty', 'updated_at'] ); } } return new StockUpdateResult($updated, $skipped); } } 

Visibility management

After stock update, we recalculate whether the product is available for order. Use an Observer or database trigger:

class StockVisibilityObserver { public function updated(ProductStock $stock): void { $totalQty = ProductStock::where('product_id', $stock->product_id)->sum('qty'); Product::where('id', $stock->product_id)->update([ 'in_stock' => $totalQty > 0, 'stock_count' => $totalQty, ]); } } 

Update Frequency and Benefits

Update frequency recommendations

With frequent updates, it's important not to overload the DB. Bulk upsert of 500 rows per query is optimal. Webhook processes changes ten times faster than CSV polling, but requires more complex infrastructure.

Benefits

Implementing automatic stock sync reduces error rates by up to 95% and ensures idempotent updates even with concurrent webhooks. Our approach ensures eventual consistency, balancing performance and accuracy. To prevent race conditions during concurrent webhook execution, we use database transactions with row-level locking. The queue worker is managed by Supervisor for reliable processing.

Error Handling and TTL

A typical problem: supplier didn't respond. We don't zero stocks. We use TTL: if data from a source is older than max_age (e.g., 4 hours), mark products as "stale" and show a warning in admin, but don't touch qty on the storefront. Using TTL of 2 hours, we reduce stale data incidents by 80%.

Implementation and Support

What's included

1. Define list of suppliers and data formats.
2. Develop parsers for each source implementing StockSourceInterface.
3. Set up scheduler for periodic CSV/API polling or webhook endpoint.
4. Implement StockUpdater with bulk upsert and SKU → product_id mapping.
5. Add StockVisibilityObserver for automatic visibility management.
6. Configure TTL and error monitoring.
7. Test on a database copy with real data.

Timelines

• One source (CSV/FTP), scheduler, bulk upsert, visibility recalculation — from 2 days.
• Multiple sources + warehouse aggregation — from 3 to 4 days.
• Webhook endpoint + sync monitoring dashboard — from 5 days.

Exact timelines are given after a free audit of your project.

Documentation and support

• Documentation: architecture description, data schema, admin manual.
• Access: FTP setup, API keys, webhook endpoint.
• Training: show how to add a new supplier and monitor sync.
• Support: fix errors during warranty period.

Contact us for a free audit of your project. Order implementation — and your stock data will always be up-to-date.