Our team specializes in custom courier delivery systems. Delivery volume grows — 50, 100, 300 orders per day. Aggregator commissions eat margins. An in-house courier service solves both: you control quality and save up to 40%. Based on our experience, operational costs drop 25–40% after implementation, and delivery time averages a 20% reduction. For example, a business with 100 orders daily can save over $5,000 per month (based on average aggregator fees). Development cost for a turnkey system typically ranges from $15,000 to $30,000 depending on features. Our engineers have completed 30+ courier delivery projects for e-commerce and food delivery. In 8–12 weeks, you get a turnkey system with a dispatcher panel, courier mobile app, and customer tracking. The courier management system consists of three components: backend, web panel, and mobile app. This article covers architecture, data models, distribution algorithms, and key implementation questions. Contact us for a detailed estimate for your system.
System Architecture
Components
- Backend: REST API + WebSocket server for real-time coordinates. Handles up to 1000 orders per day.
- Dispatcher panel: web interface for managing couriers and routes.
- Courier mobile app: React Native or PWA for receiving tasks and sending GPS coordinates every 30 seconds.
Data Model
couriers (
id, user_id, name, phone, vehicle_type,
status: offline | available | busy | on_break,
current_lat, current_lng, last_seen_at,
zone_ids (jsonb) -- delivery zones the courier is responsible for
)
delivery_tasks (
id, order_id, courier_id (nullable),
status: pending | assigned | picked_up | in_transit | delivered | failed,
pickup_address, delivery_address,
scheduled_at, picked_up_at, delivered_at,
proof_photo_url, -- photo on delivery
recipient_signature_url, -- recipient signature
failure_reason
)
courier_routes (
id, courier_id, date,
task_ids (jsonb, ordered), -- delivery order
total_distance_km, estimated_duration_min
)
Dispatcher Panel
Map with real-time couriers (Yandex Maps or Leaflet). List of unassigned orders, drag-and-drop assignment, task queue with reordering. Monitoring: if a courier hasn't moved for 20 minutes — alert to dispatcher. Route history and daily efficiency.
Courier Mobile App
Main screens:
- Task list — current route, next point.
- Navigation — integration with Yandex Navigator via deep link.
- Delivery confirmation — photo, signature, or SMS confirmation code.
- Error handling — reason: door not opened, reschedule, refusal.
Customer Tracking
Customers receive an SMS/push with a link to a tracking page for real-time delivery tracking. The page shows a real-time map with the courier and ETA, recalculated every 2 minutes.
Delivery Zones
Geographic zones — polygons on the map, stored in PostgreSQL with the PostGIS extension. PostGIS delivery zones enable efficient geospatial queries. Query executes in 5–10 ms:
SELECT * FROM delivery_zones
WHERE ST_Contains(polygon, ST_SetSRID(ST_MakePoint(lng, lat), 4326));
Handling Failed Deliveries
If courier didn't find the recipient, status becomes failed with reason. Automatically schedules a redelivery for the next day or the customer picks a new time. Dispatcher gets notified.
Infrastructure Requirements
Two servers suffice: one for backend and database, another for WebSocket server and queues. For up to 1000 orders per day, use PostgreSQL with PostGIS and Redis for caching. Optimal configuration: 4 vCPU, 8 GB RAM per server.How Does Automatic Order Assignment Work?
Manual assignment: dispatcher drags an order onto a courier on the map — suitable up to 50 orders per day. Automatic routing uses the Vehicle Routing Problem (Wikipedia) algorithm. Route optimization is achieved via VRP algorithms. For small volumes, a greedy algorithm (nearest available courier). For serious optimization, Google OR-Tools or services like OptimoRoute, Route4Me. Automatic assignment is 100–600 times faster than manual dispatch.
| Criteria |
Manual Assignment |
Automatic (VRP) |
| Dispatch time per order |
5–10 min |
1–2 sec for entire route |
| Route optimality |
Depends on experience |
Mathematically optimal |
| Scalability |
Up to 50 orders/day |
Any quantity |
| Implementation cost |
Free (built-in) |
Requires OR-Tools integration or API |
Switching to automatic distribution reduces dispatch time by 100–600 times. Contact us to discuss automating your dispatch.
# Simple heuristic: assign nearest available courier
def assign_courier(task):
available_couriers = Courier.objects.filter(status='available')
nearest = min(available_couriers,
key=lambda c: haversine(c.location, task.pickup_address))
task.assign(nearest)
Routing Tools Comparison
| Tool |
Type |
Free? |
Accuracy |
Scalability |
| Google OR-Tools |
Library |
Yes (Apache 2.0) |
High |
Up to 200 points |
| OptimoRoute |
API |
Commercial |
Very high |
Unlimited |
Why Is In-House Delivery More Profitable?
In-house delivery is 2–3 times cheaper than using aggregators. Aggregator commissions eat margins. In-house delivery costs 2–3 times less than aggregators starting at 100 orders per day. The system pays off at 50+ orders per day. Savings on aggregator commissions reach 40% at 100+ orders, with payback period of 6–8 months. You gain full brand control, flexible pricing, delivery cost calculation, and all data for analytics. ETA accuracy is ±3 minutes. We guarantee stable operation even during peaks — proven on 30+ projects.
Implementation Process
- Analytics: study your business process, order volume, geography.
- Design: architecture, data model, interface prototype.
- Development: backend, dispatcher panel, mobile app.
- Testing: load testing, usability tests with real couriers.
- Deployment: on your server or cloud, team training.
What's Included
- REST API and WebSocket server for real-time tracking
- Dispatcher panel on React with map and drag-and-drop
- Courier mobile app (React Native) with navigation and photo capture
- CRM/ERP integration via API
- Documentation and training
- 3 months warranty support
Our turnkey development process includes all stages. Development time for a complete turnkey system is 8–12 weeks. Cost is calculated individually based on your requirements. For a consultation and estimate, contact us.
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
| Step |
Duration |
| Requirements audit (which services, scenarios, tracking needs) |
2–3 days |
| Architecture selection and backend implementation |
1–2 weeks |
| Pickup point caching + rate caching implementation |
2–3 days |
| Frontend widget (map, list, filters) |
1–2 weeks |
| Testing with real requests in test mode |
3–5 days |
| Deployment and post-launch support |
2 days |
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
| Scenario |
Timeline |
| One service (CDEK or Boxberry), WooCommerce |
1–2 weeks |
| Two or three services + map widget |
3–5 weeks |
| Full multi-carrier + tracking + notifications |
6–10 weeks |
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.
