Product Guides

How to Use the vRouted API to Automate Route Optimisation

8 min read

The dashboard is the right tool when a planner is clicking through routes by hand. It's the wrong tool when routes are being generated automatically from another system - an order platform, a booking tool, an internal ops dashboard - because a human clicking a UI shouldn't be the integration point between two pieces of software. That's what the API is for.

What the API is for

vRouted's API covers the same core resources the dashboard is built on: vehicles, routes, and optimisation, plus fleet-wide multi-vehicle optimisation for larger jobs. Full details, including request and response shapes, are documented at /api-docs - this piece is about the integration pattern, not a full reference.

A typical integration pattern

The common shape looks like this: an upstream order or booking system accumulates a batch of stops that need routing, and instead of a human re-entering them into the dashboard, your own backend calls the optimisation endpoint directly whenever that batch is ready. The route comes back as structured data your system can hand straight to a driver-facing app or an internal dispatch view, with no manual re-entry step in between.

Basic vs. advanced optimisation endpoints

There are two optimisation endpoints, and which one you want depends on how much constraint detail your use case needs. The basic optimise endpoint takes a start location, a set of destinations, and a vehicle type, and returns a sequenced route with distance, time, and pricing. The advanced endpoint adds real constraint support - specific vehicle capacity, time windows, workload balancing - at the cost of needing more structured input (a specific vehicle ID rather than just a type, and an explicit constraints object). Start with the basic endpoint if your use case doesn't need hard constraints yet; it's simpler to integrate and easier to debug.

Authentication

API access uses the same session-based authentication as the dashboard - email/password or Google sign-in - rather than a separate API-key system. For a backend-to-backend integration, the simplest approach is a dedicated login used only by your integration, kept separate from any individual person's account, so the credential's purpose is unambiguous if it ever needs to be rotated.

Handling geocoding failures gracefully

Because addresses in an automated integration come from an upstream system rather than a human typing them in, they won't always resolve cleanly. Build for the failure case explicitly - a response indicating which addresses couldn't be geocoded - rather than assuming every request will succeed. That's the same address-quality problem covered elsewhere on this blog, just surfacing at the API layer instead of a manual entry screen.

Getting started

The API Testing tab on /api-docs lets you try real requests against your own account before writing any integration code. Test with a handful of real orders first, confirm the response shape matches what your system expects, and only then wire it into a live pipeline - the same incremental approach that makes sense for adopting route optimisation in general applies just as much to automating it.

About the author

Founder of Anteam, the East Midlands industrial AI company behind vRouted. She led development of Anteam's ant-colony-inspired route-matching platform, backed by the Department for Transport, Innovate UK and the University of Cambridge Institute for Sustainability Leadership.

Planning multi-drop rounds for a UK fleet? Read the guide to route planning software for multi-drop distributors.

#API#Developers#Automation#Integration

Ready to plan your rounds with vRouted?

Book a 20-minute call and see how vRouted plans your rounds against capacity, delivery windows and driver hours.