Custom transport planning API development
Appfront builds custom transport planning APIs for logistics and haulage companies that want to automate their route planning, fleet scheduling and route optimisation. Under the bonnet: VRP solvers based on OR-Tools, proprietary ETA models, geocoding and rate shopping. On the outside: a clean REST API that connects seamlessly to your TMS, telematics, ERP and customer portals.
What is a transport planning API?
A transport planning API is a programmable layer around your planning logic. Instead of planners manually allocating orders to vehicles or getting stuck in a closed SaaS tool, you get your own API endpoint that receives orders, vehicles, drivers and restrictions, and returns an optimised set of routes within seconds. Under the bonnet, geocoders, a Vehicle Routing Problem solver and ETA models run, tailored to your type of transport and your business rules.
For many hauliers, this is a logical next step after choosing a TMS. A TMS organises orders, invoicing and driver dispatch, but the optimisation itself is often based on rules of thumb and manual corrections. A planning API takes over that optimisation and returns the results to the TMS, without you having to replace your TMS. We often see this pattern in projects around custom transport software: the TMS remains the operational core, and the planning API runs alongside it as a smart add-on.
Appfront designs these APIs so they don't become black boxes. The solver settings, business rules, model versions and evaluation metrics can be inspected by your own planners and IT team. Integrations run over standard REST and webhooks, documented to OpenAPI, so external parties — a new customer portal, a new telematics provider — can connect almost straight away. You can read more about this approach on our page on smart API integrations.
VRP solver, not manual shuffling
OR-Tools or VROOM calculates the optimisation with the constraints your planners normally keep in their heads: time windows, weight classes, driver skills, environmental zones, ADR. The solver delivers a complete plan within seconds, and planners handle the exceptions.
ETA based on your own history
Not a generic Google ETA, but an arrival-time model trained on your own trip logs, vehicle types and routes. Waiting times at loading and unloading addresses, busy corridors and seasonal effects are built into the model, so customer ETAs are accurate.
Open integration with your TMS
The API runs alongside Transics, Carrierweb, i-teq or another TMS. Orders and vehicles are read in via REST or message queues, and the optimised plan flows back. Your TMS remains the operational source, while the optimisation becomes visible and controllable.
Our development process for a planning API
A good planning API doesn't start with code, but with the planners who do the work today. We work alongside them to surface the real constraints — often unwritten knowledge held for years in the heads of senior planners. Only then do we choose the solver, the data model and the integrations. That way you get an API that is not only mathematically optimal but also trusted in practice by the team that has to use it every day.
We join the planning process for several days, mapping constraints, exceptions and KPIs. Without that context, any VRP solver will fail in week one.
OR-Tools, VROOM or a hybrid approach, depending on scale, constraints and required computation times. We define the data model and the OpenAPI contracts.
Iterative development with automated tests and shadow runs alongside your current planning. Planners see results and provide feedback before we go live.
Controlled rollout per depot or region, with monitoring of solver quality, ETA errors and exception rates. This is followed by ongoing management and refinement.
What a planning API delivers in practice
Every planning API is tailored to the type of transport and the carrier's existing systems. Below are the components we consistently see, which can be combined depending on your scenario. What is described on this page builds on the more general context we outline in what an API integration is, applied to the specific challenges of transport.
Route planning & VRP solver
Orders, vehicles, drivers and constraints are distributed by the solver across routes with minimal cost or CO₂ emissions. Time windows, capacity, skills, ADR and environmental zones are built into the model as constraints. Your planners handle the exceptions, while the solver does most of the work.
Geocoding & address validation
Order addresses are converted into coordinates via PDOK, Photon or Nominatim, corrected for spelling errors and validated against postcodes and BAG registers. From a single API endpoint you receive reliable lat/lon pairs that the solver can calculate with.
ETA prediction
An arrival-time model trained on your own historical trip data, supplemented with traffic sources and weather information. Waiting times at specific loading and unloading addresses, weekend effects and seasonal patterns are built into the model, so customer ETAs are accurate and planners handle fewer calls.
Rate shopping & carrier selection
For shippers and logistics service providers using multiple carriers: rates from charter, scheduled-service and parcel carriers are requested, validated and compared in real time. The API selects the optimal combination of price, transit time and reliability based on your own criteria.
Capacity forecasting
Based on historical order patterns and seasonal effects, the API predicts how many vehicles and drivers you will need in the coming days or weeks. Staffing and charter planning thus becomes data-driven rather than reactive, which is especially valuable for seasonally sensitive operations.
Exception handling
Traffic jams, no-show customers, broken vehicles, last-minute orders: exceptions are the norm in transport. The API offers re-planning endpoints that can quickly generate an adjusted schedule without replanning the whole day. Planners stay in control, while AI does the heavy lifting.
Typical scenarios in practice
A transport planning API looks different for each type of business. We consistently see a number of recurring scenarios, and for each we have a recognisable approach that takes into account the specific rules, constraints and systems common in that market. Also read our broader view of this sector in transport & logistics.
Distribution & FMCG
Distributors who plan hundreds to thousands of stops a day from one or more DCs. The API takes into account time windows, weight, volume and vehicle type. Results flow back into Transics or a comparable TMS, so planners can focus on exceptions instead of manually shifting stops.
Last-mile & e-commerce delivery
Online retail delivery services and last-mile carriers who promise consumers delivery time slots and need to deliver on them. The API combines VRP with real-time ETA prediction and sends slot suggestions back to the customer portal, so that the slots on offer and operational reality stay in sync.
Food & pharma with cold chain
Temperature-sensitive logistics where cold-chain requirements, four-eyes checks and HACCP or GDP requirements are built into the planning. The API knows vehicle cold compartments, do-not-combine rules and specific loading and unloading sequences, so compliance is already secured in route selection.
Construction logistics & project transport
Construction logistics with arrival windows at the site, permit documents, environmental zones and ADR requirements. The API works on the basis of resource-driven planning, where each journey often has its own requirements, making it suitable for forwarders who do more than standard line haulage.
Technology we use
We tailor the technical stack to your scale, constraints and existing IT landscape. We use proven open-source components where possible and our own models where they add value. The API itself is built in a language and framework that your own team can continue to maintain, with no vendor lock-in and no secret sauce.
Why Appfront for your planning API?
Appfront has extensive experience building APIs for transport and logistics, and with the mathematical side of planning. We know that a VRP solver only becomes meaningful once planners trust it, that an ETA model only works when it is trained on your own data, and that an API is only valuable when it fits what is already in place. That is why we always start with the planners and your existing TMS, not with a blank solver sheet.
For every integration we write clear documentation and OpenAPI contracts so your own team, or a future supplier, can understand and manage what is running. No black box, but transparent code and clear agreements on solver settings, model versions, monitoring and management. This keeps you independent and in control of your planning logic at all times — a requirement that becomes increasingly important legally under the AI Act for algorithms that direct people or vehicles.
You work with a dedicated point of contact who understands both the optimisation and the integration side. This keeps lines short, prevents miscommunication between your TMS supplier, telematics partner and internal IT, and speeds up decisions when choices need to be made during the build around data models, constraints or ETA models.
See also our broader overview of integrations we build and how we approach API integrations in general. The planning API is a specialised application of that.
- Experience with OR-Tools and VROOM in production
- Specialist in transport and logistics software
- Custom ETA models based on your historical data
- Experienced with Transics, Carrierweb and i-teq adapters
- Telematics integrations with Webfleet, Trimble, Geotab, MiX
- Geocoding based on PDOK, Photon and custom corrections
- OpenAPI 3 contracts, no undocumented endpoints
- Secure by default: API keys, scoped permissions, rate limiting
- EU-resident hosting (Azure West Europe, AWS Frankfurt, Dutch cloud)
- AI Act preparation for scheduling algorithms
- A fixed point of contact, no account managers passed around
- Ongoing maintenance, monitoring and model updates
Security, GDPR, EU residency and the AI Act
Transport data is sensitive: driver personal data, GPS routes, driving and rest times and order information fall under the GDPR and under sector-specific rules. The algorithms that act on this data are also subject to the European AI Act. Appfront builds to the OWASP ASVS standard and, for every planning API, explicitly defines which personal data is needed, who has access to it and how long it is retained.
We host within EU residency by default — Azure West Europe, AWS Frankfurt or a Dutch cloud provider of your choice — and encrypt data both in transit and at rest. We document the data flows between your TMS, telematics, customer portal and planning API so that your record of processing activities is complete and you can demonstrably comply with the GDPR. For driving and rest times, we take EU Regulation 561/2006 into account: data is not kept longer than legally permitted and is only accessible to the functions that genuinely need it.
For the AI components — the VRP solver, the ETA model and any assignment algorithms — we deliver model cards, a description of training data provenance and evaluation metrics. This enables you to demonstrate under the AI Act that decisions are transparent and explainable. For algorithms that direct drivers — for example workload balancing — we provide an impact assessment and human-oversight procedures, in line with the requirements placed on high-risk AI. Please also read our information security policy and coordinated vulnerability disclosure policy.
- GDPR-compliant processing of driver and customer data
- EU residency: Azure West Europe, AWS Frankfurt or Dutch cloud
- AI Act: model cards, dataset provenance, evaluation metrics
- Impact assessment for algorithms that direct drivers
- EU 561/2006 — driving times in line with the statutory retention period
- eCMR-compliant digital consignment notes with an audit trail
- Encryption in transit (TLS 1.2+) and at rest
- API key rotation and role-based access
- Rate limiting and DDoS protection
- Audit logs with traceable data flows
- Monitoring and alerting for solver and model deviations
- Documentation for your record of processing activities
Frequently asked questions about a transport planning API
Answers to the questions we are asked most often about custom planning APIs for transport and logistics.
A transport planning API is a custom, programmable layer around your planning logic. Instead of manually dragging trips around in a TMS screen or planning via a closed SaaS button, the API offers endpoints for entering orders, vehicles, drivers and constraints, and returns optimised routes as a structured response. Under the hood run geocoders, a VRP solver (for example OR-Tools) and ETA models that take into account driving times, time windows, capacity and historical traffic patterns.
SaaS tools such as Routigo, PTV Smartour or Stratumn work well for standard distribution, but often hit their limits on specific constraints: weight classes, low-emission zones, permit documents, refrigerated routes, four-eyes checks, ADR, partial loads or customer-specific loading arrangements. Your own planning API gives you control over the optimisation goal, the business rules and the way the solution connects to your own TMS, ERP and driver apps. In addition, the data stays within your own domain, which is increasingly important under the AI Act for algorithms that steer people or vehicles.
For the VRP component we typically work with Google OR-Tools (CP-SAT and the Routing Library) or with VROOM, depending on scale and the type of constraints. For pure shortest-path and isochrones we use OSRM or GraphHopper on top of an up-to-date OpenStreetMap extract; for geocoding we combine local geocoders with Photon/Nominatim or the PDOK location server for Dutch addresses. We train ETA prediction as a gradient-boosting model or a lightweight neural network on your own historical trip data, supplemented with external traffic and weather series. Which combination fits best is determined after a short data discovery.
We build the API as an independent service that communicates with your existing systems via REST, webhooks and, where needed, message queues. For Transics, Carrierweb, i-teq or any other TMS, we deliver adapters for orders, vehicles, drivers and planning results. For telematics (Webfleet, Trimble, Geotab, MiX) we ingest position and driving behaviour data in real time. For ERP and accounting we connect via the common connectors (SAP, Microsoft Dynamics, Exact, AFAS). This means the planning API is the only place where the optimisation logic lives, while the rest of your IT landscape remains untouched.
Costs depend on the complexity of your constraint set, the number of orders and vehicles you plan each day, the required computation times, the number of systems to integrate, and the extent to which you want your own models for ETA, demand forecasting or carbon reporting. Monitoring, maintenance and how much you want to manage yourself also play a role. After a no-obligation analysis, we'll send you a clear quote covering the scope and any phased delivery.
Yes. We host the API within EU residency (Azure West Europe, AWS Frankfurt or a Dutch cloud of your choice) and build in line with OWASP ASVS. Driver data, trip logs and GPS tracks fall under the GDPR and are retained only for the minimum necessary period, encrypted in transit and at rest. For the AI components, including the VRP solver, the ETA model and any assignment algorithms, we record model cards, training data provenance and evaluation metrics, so you can demonstrate under the AI Act that decisions are transparent and explainable. For algorithms that direct drivers, we provide an impact assessment and human-oversight steps.
Yes. Appfront regularly takes over existing planning services, sometimes originally written by an in-house IT team and sometimes by another supplier. We review the solver configuration, business rules, API contracts and monitoring, document the current setup and draw up an improvement plan. From that point, we can take responsibility for extensions, performance tuning and ongoing maintenance, including rolling out new models for ETA or capacity forecasting.
A transport planning API is most worthwhile when you plan large volumes of orders, vehicles or stops daily and standard SaaS tools no longer suffice. Typical profiles include medium-sized to large road hauliers, distribution and delivery companies, couriers with their own consumer portal, construction logistics, food and pharma logistics with strict time windows, last-mile delivery providers and logistics service providers with multiple clients per route. For smaller fleets, a targeted, lighter VRP service may be sufficient.
Talk to us about your planning API
Tell us how you currently plan, which TMS and telematics you use, and what you would like to automate: VRP, ETA, rate shopping, capacity forecasting or exception handling. We are happy to think along with you on scope, priorities, data model and alignment with your existing suppliers. A no-obligation first conversation will give you a clear picture of what is feasible for your situation.