.png)
Most embedded routing and scheduling APIs ship one endpoint: solve. POST a problem, GET a plan. Once your platform is running real operations, the bar moves fast. Five depth capabilities (Evaluate, Suggest, synchronous re-optimization, time-dependent traffic, and advanced pickup-and-delivery) plus the managed-vs-self-hosted axis separate a batch-mode solver from operational infrastructure.
The first time a field service or last-mile platform integrates a routing engine, the bar is simple. POST a problem, GET a plan. Solve. That's enough to ship.
The bar moves fast.
Within months, your operators hit cases the solver wasn't asked to handle. A technician finishes early and the dispatcher wants to know whether reassigning the next available job is worth it. A boiler emergency at 10am, and someone has to decide which afternoon stops to push, reassign, or absorb. Friday 4pm traffic doesn't match the routing matrix used at 8am Monday. A customer requests a same-day pickup tied to a delivery that's already on the route.
None of those are "re-solve everything" problems. They're depth problems. They're what an embedded routing API has to support when routing stops being a morning batch and becomes part of the operational loop.
This is about that depth, and the five places it shows up.
A lot of embedded or home-grown routing and scheduling solvers ship one endpoint that matters. Solve. POST a JSON, GET a plan. It handles the textbook 80% of the use case for the textbook 80% of platforms.
It also forces every downstream operational decision back through "re-solve the whole thing." That's slow, expensive, and not how dispatchers actually work. Dispatchers evaluate. They compare. They look for a single move that fixes one problem without breaking five others.
If your platform is going to be the system of record for live field operations, the API underneath has to support that loop.
Submit an existing plan. Get it scored against the full constraint model. Without re-solving.
Use it to:
For the operator inside your platform, this is the difference between "trust the optimizer" and "see the trade-off." It's also a credible answer to the "why did the system route it this way?" question every FSM dispatcher asks at least once a week.
A lot of optimization engines don't ship this endpoint. They solve. Then they re-solve. That's their answer to evaluation.
Ask the solver where to insert a new job in the current plan. Get ranked alternatives with cost deltas, without re-running the full schedule.
A boiler emergency at 10am isn't a re-solve problem. It's an insertion problem. The Suggest endpoint answers it in under a second. The dispatcher sees the best slots, picks one, and the rest of the day stays intact.
This is the endpoint that turns a routing engine from a daily planner into an operational assistant.
Real-time re-optimization on the live plan. A synchronous request resolves the affected sub-problem and returns an updated plan in under five seconds, with original constraints intact.
It isn't "solve everything again." It's "the world changed at job 12, re-optimize from there forward, hold the morning that already happened in place." That distinction is the gap between a routing engine that's part of the dispatch loop and one that's only useful before the day starts.
Time-dependent travel-time matrices. Drive time at 8am is not drive time at 4pm. The solver knows. So does the resulting plan.
A lot of optimization APIs run on a flat distance matrix and call it good. That's the wrong model for any operation where on-time arrival drives customer outcomes. Arriving late at an emergency job, missed SLAs, technicians stuck behind a school zone at pickup time. None of that shows up in the solve until the travel-time model accounts for time of day.
It's one of the quietest depth differentiators. It's also one of the loudest in the field.
Most routing engines that mention pickup-and-delivery support the basic case. Pick something up here. Drop it off there.
Real operations rarely look like that.
A technician picks up a part at the depot, delivers it on the way to a customer site, services the equipment, picks up returned inventory at end of day, and drops it at a different depot. Each leg has its own time window. Each leg has its own capacity constraint. The pickup is tied to a downstream service window through a job relation, so if the depot pickup slips, the service slot has to move with it.
That's the constraint model real field service and last-mile operations have. The solver has to model it natively. A post-process layer that stitches solves together doesn't hold up under operational load.
There's a depth axis that doesn't get talked about enough: who runs the solver.
Self-hosted optimization engines (open-source cores plus enterprise license keys for the production features) move the operational burden to the buyer. Your team runs the JVM. Your team patches versions. Your team owns scaling, failure modes, regression testing across solver releases, and the on-call rotation when a customer's morning planning run doesn't finish.
A managed routing API takes that off the table. Solver versioning, scaling, performance work, regression testing on constraint changes, all of that sits with the API provider. The OEM platform integrating it gets one HTTP surface, with SLAs.
For a platform team trying to ship product, "we don't run optimization infrastructure" is one of the better trade-offs available.
V3 of OnRoute is a new architecture, built for platforms whose depth requirements have only grown. Faster solves on larger problems. More flexible constraint composition. Same API surface, so existing integrations stay in place.
If you're evaluating an embedded routing engine for your platform and you've already mapped the operational loop your customers actually run, talk to us. The depth side of the API is where we live.
