How to Use the VRouted API to Automate Route Optimization
The dashboard is the right tool when a dispatcher 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 optimization, plus fleet-wide multi-vehicle optimization 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 optimization 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 optimization endpoints
There are two optimization endpoints, and which one you want depends on how much constraint detail your use case needs. The basic optimize 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 optimization in general applies just as much to automating it.