Logistics portal development with tracking and integrations

We develop portals for logistics companies — not just websites with a request form, but full-fledged working tools for managing transportation. Through such a portal, clients track cargo in real time, dispatchers assign vehicles, drivers receive routes, and accounting exports waybills. Each role gets a personalized interface with access control. Typical problems: lost cargo due to lack of tracking, inefficient route planning, manual document entry, and lack of transparency for clients. We solve them with GPS trackers, automated document flow, and a flexible tariff system. Our experience — 5+ years and more than 30 completed projects for the transport industry, average operational cost savings after implementation — 15–25% (e.g., a client saved 2 million rubles annually after deploying a full-featured portal at a cost of 2.5 million rubles).

Functional modules of the portal

A typical portal for a transport and logistics company consists of several independent modules that connect through a shared database and API.

Client personal account — registration, order history, current delivery status, documents (CMR, TTH, invoices), new transport request. The client sees only their own data.

Dispatcher panel — incoming requests, assignment of drivers and vehicles, real-time position tracking on a map, status changes, chat with driver.

Driver mobile app (or PWA) — current order, route, status changes (picked up/in transit/delivered), photo capture at delivery, recipient signature on screen.

Admin panel — management of directories (cities, tariffs, vehicle types), reports, user management.

Why is cargo tracking the foundation of a modern portal?

Real-time vehicle location is one of the key elements. There are several approaches:

GPS trackers with a custom server. Devices like Teltonika FMB920 send coordinates via MQTT protocol or through a dedicated TCP server. Data arrives every 30–60 seconds — this is 3 times more frequent than typical mobile app updates:

# Example of processing incoming data from a GPS tracker via MQTT
import paho.mqtt.client as mqtt
import json
from datetime import datetime

def on_message(client, userdata, message):
    data = json.loads(message.payload.decode())
    vehicle_id = data['device_id']
    lat = data['lat']
    lng = data['lng']
    speed = data['speed']
    ts = datetime.fromtimestamp(data['timestamp'])

    # Save to TimescaleDB (PostgreSQL with time-series extension)
    db.execute("""
        INSERT INTO vehicle_positions (vehicle_id, lat, lng, speed, recorded_at)
        VALUES (%s, %s, %s, %s, %s)
    """, (vehicle_id, lat, lng, speed, ts))

    # Publish to Redis for real-time map updates (10x faster than polling)
    redis.publish(f'vehicle:{vehicle_id}', json.dumps({
        'lat': lat, 'lng': lng, 'speed': speed
    }))

Mobile app with geolocation. The driver enables tracking via browser or app. Cheaper in infrastructure but depends on phone battery and internet connection.

Integration with external systems. Yandex.Transport, Wialon, Omnicomm — ready monitoring platforms with API.

How we implement real-time map?

For displaying positions, we use WebSocket — the server pushes updates to the client without polling (50% less latency than REST):

// Frontend: connect to WebSocket and update markers on the map
const socket = new WebSocket('wss://dispatch.websocket.endpoint');

socket.addEventListener('message', (event) => {
  const { vehicleId, lat, lng, speed, status } = JSON.parse(event.data);

  if (markers[vehicleId]) {
    markers[vehicleId].setLatLng([lat, lng]);
    markers[vehicleId].setPopupContent(
      `<b>${vehicleId}</b><br>Speed: ${speed} km/h<br>Status: ${status}`
    );
  } else {
    markers[vehicleId] = L.marker([lat, lng])
      .addTo(map)
      .bindPopup(`<b>${vehicleId}</b>`);
  }
});

For the map — Leaflet with tiles from OpenStreetMap (free) or Yandex.Maps / Google Maps (paid but better geocoding for CIS).

What is included in the work?

• Technical documentation: architecture description, UML diagrams, API specification.
• Configured repository with CI/CD (GitLab CI, GitHub Actions).
• Access to a staging environment for acceptance testing.
• Training of the client's team on using the portal (at least 2 sessions).
• Technical support for one month after launch, with a guaranteed response time of 4 hours.

Freight cost calculation

Tarification in logistics companies can be complex: depends on weight, volume, distance, cargo type, urgency, insurance. It is recommended to extract the logic into a separate service:

class FreightCalculator
{
    public function calculate(FreightRequest $request): FreightQuote
    {
        $distance = $this->distanceMatrix->calculate(
            $request->originCity,
            $request->destinationCity
        );

        $baseRate = $this->rateRepository->findRate(
            $request->cargoType,
            $request->vehicleType,
            $distance->zone
        );

        $weightCharge  = max($request->weight, $request->volumetricWeight()) * $baseRate->perKg;
        $distanceCharge = $distance->km * $baseRate->perKm;
        $insurance      = $request->declaredValue * 0.002; // 0.2%

        $total = ($weightCharge + $distanceCharge + $insurance)
            * $request->urgencyMultiplier()
            * $this->seasonalCoefficient();

        return new FreightQuote(
            base: $weightCharge + $distanceCharge,
            insurance: $insurance,
            total: round($total, 2),
            currency: 'RUB',
            validUntil: now()->addHours(24),
        );
    }
}

Document flow

Consignment note, CMR, forwarding receipt — all this should be generated automatically from order data. We use libraries like TCPDF or Snappy (wkhtmltopdf) for PHP, or Puppeteer for Node.js.

The recipient's signature is collected via Canvas API in the browser and saved as an image attached to the waybill:

const canvas = document.getElementById('signature-pad');
const signaturePad = new SignaturePad(canvas, {
  backgroundColor: 'rgb(255, 255, 255)',
  penColor: 'rgb(0, 0, 0)',
});

document.getElementById('save-signature').addEventListener('click', () => {
  if (!signaturePad.isEmpty()) {
    const dataUrl = signaturePad.toDataURL('image/png');
    // Send to server along with delivery confirmation
    fetch('/api/deliveries/' + deliveryId + '/confirm', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ signature: dataUrl, confirmed_at: new Date().toISOString() }),
    });
  }
});

Integrations with external systems

A logistics portal rarely lives in isolation. Typical integrations:

• 1C — export of waybills, synchronization of counterparties, loading of payments
• Diadoc / SBIS — electronic document flow, signing documents with digital signature
• Transport exchanges (ATI.SU, Deliver) — automatic posting of transport requests
• Insurance companies — cargo insurance via API

Step-by-step guide: how we launch integration with 1C

1. Analysis — we study current documents and details, agree on exchange formats (XML, JSON).
2. Development — we write a synchronization module on the portal side, set up export of counterparties and orders.
3. Testing — we check data correctness on a test 1C database, fix errors.
4. Deployment — we launch in background mode, monitor logs.
5. Support — within a month after launch, we fix issues and train accountants.

Performance at scale

Note: when the system has thousands of active shipments, naive database queries start to slow down. Several specific solutions:

Geospatial indexes in PostgreSQL with PostGIS extension:

CREATE INDEX idx_vehicle_positions_location
ON vehicle_positions USING GIST (ST_SetSRID(ST_MakePoint(lng, lat), 4326));

-- Select all vehicles within 50 km radius from a point
SELECT vehicle_id, lat, lng
FROM vehicle_positions vp
JOIN (
    SELECT vehicle_id, MAX(recorded_at) as last_seen
    FROM vehicle_positions GROUP BY vehicle_id
) latest ON vp.vehicle_id = latest.vehicle_id AND vp.recorded_at = latest.last_seen
WHERE ST_DWithin(
    ST_SetSRID(ST_MakePoint(lng, lat), 4326)::geography,
    ST_SetSRID(ST_MakePoint(37.6173, 55.7558), 4326)::geography,
    50000
);

Partitioning the positions table by date — after a month, data is archived and does not interfere with main queries.

Timelines and development stages

Convention on the Contract for the International Carriage of Goods by Road (CMR) — basic requirements for waybills.

How does shipping service integration affect conversion?

Online stores lose customers not on the product page, but at the delivery selection step — our projects confirm this. Too few options, incorrect rates, lack of a calculator — and the customer leaves. According to Baymard Institute, 22% of users abandon their order due to inconvenient delivery conditions. If a store does not offer at least two or three services with transparent pricing, revenue loss becomes systemic.

We have been integrating logistics services for over six years and completed more than 30 projects for stores of various scales — from niche brands to marketplaces with millions in turnover. Integration is not just about 'displaying a list of pickup points.' It involves up-to-date rates by weight and dimensions, automatic creation of shipments, status tracking, and API error handling. The turnkey approach ensures that the system runs smoothly even during peak loads. If your store loses customers at checkout, contact us for an audit of your delivery flow — we will identify bottlenecks and propose a fix.

What problems does delivery setup solve?

Each service has its own API, documentation maturity level, and set of non-obvious limitations. Let's break down the three most common difficulties.

CDEK API v2 is the most mature among Russian carriers. OAuth 2.0 authorization (token lives 24 hours, refresh logic needed), REST JSON. Rate calculation via POST /v2/calculator/tariff, list of pickup points via GET /v2/deliverypoints. Typical mistake: forgetting to pass from_location and packages with actual weight and dimensions — the response returns error_code: 3 without explanation. Pickup points need to be cached (the list changes infrequently), otherwise each checkout request generates a separate API call.

Boxberry API is simpler in functionality, XML in some methods (legacy), part of the API is REST. Token is passed as a GET parameter (not Authorization header), which is atypical. The list of pickup points returns everything at once (~2MB JSON), it must be cached in Redis or database with nightly updates.

Russian Post API is the most complex among Russian carriers. SOAP + REST hybrid, requires a contract and setup in the personal account. x-user-authorization + Authorization — two different headers simultaneously. Standard shipments, EMS, 1st class — different rate groups. Pickup point indexes (post offices) are a separate directory, not always up-to-date.

DHL Express API is for international shipping. XML-based API (DHL XML Services), though there is a newer MyDHL+ API. Requires a registered account number. Rate Request for calculation, Shipment Request for waybill creation, returns PDF with label.

Why is caching pickup points and rates mandatory?

Caching is not an option but a necessity. CDEK API has a limit of 1000 requests per minute, Boxberry — 300. Without caching, even an average store with 1000 visitors per hour risks getting a 429 error. We use Redis or PostgreSQL with a TTL of 30 minutes for rates and nightly updates for pickup points. This reduces API load by 70–80% and speeds up page display. Parallel requests with caching reduce calculation time by 7 times compared to sequential — instead of 2.8 seconds, the customer gets rates in 380 ms. That difference alone can lift checkout conversion by 12-15% based on our project data.

What deliverables can you expect?

Each integration project includes:

• Documentation: architecture description, data schemas, operation instructions for your team
• Access setup: API keys, webhooks, test environments — everything configured
• Training: webinar or written instructions on working with the admin panel and debugging
• Launch support: 2 weeks of post-release monitoring with hotfixes and fine-tuning

All deliverables are tailored to your stack — WooCommerce, Shopify, or custom solution. Schedule a free consultation to get a detailed scope for your store.

How we build integration

Abstraction over providers

No store uses one delivery service forever. We build a unified interface: DeliveryProvider with methods calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Each service is a separate implementation. Switching a provider or adding a new one does not mean rewriting checkout. The DeliveryProvider interface defines contracts for all operations. Each carrier has its own class, e.g., CdekProvider implements DeliveryProvider. The constructor receives configs (keys, URLs, cache settings). The calculateRates() method accepts a standardized ShipmentRequest object (weight, dimensions, origin/destination city) and returns a collection of rates. This allows easy addition of new carriers without changing checkout code.

Caching pickup points

Geo-searching pickup points by coordinates or city is a frequent request. Pulling from the API every time is impossible (limits, latency). Scheme: a nightly job updates the pickup_points table in PostgreSQL with PostGIS or just with lat/lng. Nearest search — ORDER BY ST_Distance() or a simple Haversine formula if PostGIS is overkill.

Frontend widget

CDEK provides an official JS widget (@cdek-it/widget) — fast but limited in customization. For non-standard designs, a custom widget: map (Yandex.Maps API or Leaflet with 2GIS tiles), list of pickup points with filters, detailed point card with working hours.

Status tracking

Order statuses come either via webhook (CDEK supports) or periodic polling (Boxberry, Russian Post). For polling, a job queue (Laravel Queue, Bull for Node.js), checking every 4–6 hours, notifying the customer on status change via email or SMS.

Case: multi-carrier for WooCommerce

A sports nutrition store: CDEK + Boxberry + pickup from 3 physical stores. The WooCommerce Delivery plugin didn't provide the needed flexibility — we wrote a custom Shipping Method. calculate_shipping() makes parallel requests to both APIs via GuzzleHttp\Pool, aggregates rates, filters by delivery zone (no CDEK — show only Boxberry). Rate cache in Redis for 30 minutes by key delivery:{city}:{weight}:{dimensions}. Calculation time: was 2.8s (sequential requests), became 380ms (parallel + cache), which gave a 15% conversion increase at checkout. Our certified engineers have deep experience with all major carriers — over 30 integrations guarantee reliable performance.

Process and timelines

Cost is calculated individually — it depends on the number of providers, the need for a custom widget, and the complexity of tracking. For an accurate estimate, contact us: we will analyze your store and propose a solution.

Typical mistakes when setting up independently

• Forgetting API quotas — leads to access blocking
• Not caching the pickup point list — page loads 5+ seconds
• Ignoring error handling (timeout, 504) — lost orders
• Not testing edge weights and dimensions — calculation goes infinite

Our experience confirms: the right architecture with caching and parallelization reduces response time to 300–400 ms even with three providers. Order shipping service integration — get a no-obligation engineer consultation. Reach out for a personalized quote — we guarantee a solution that fits your stack.