Glossary

Term	Definition
Agency	The sandbox or production account scope every plan belongs to, derived automatically from the API token used to make the request (`AgencyId` in API responses). See Moving from sandbox to production.
Resource	A vehicle-driver pair for the duration of a plan — id, working hours, capacities, skills, tags, and travel profile. Called `Resource` in the API. See Data model.
Order	One or more `stops` that must all be planned onto the same resource, in array order. Called `Order` in the API. See Data model.
Stop	A single visit (`SingleStop`), or a group of alternative visits of which the engine picks at most one (`AlternativesStop`), nested inside an order. See Data model.
Unique stop	The billing unit: a stop counted once per plan and per 24-hour period, as long as it keeps the same `id` and doesn’t move by more than about 11 metres. See Pricing and credits.
Tag	A free-form string label attached to a resource or a stop (`tags`, `requiredSkills`, `preferredStopTags`, and others) — the API defines no built-in tag values, and two sides only match by exact string. See Driver skills and qualifications.
Capacity	A free-form named dimension (weight, volume, a headcount, and so on) tracked independently on both resources and stops; a key the stop consumes but the resource doesn’t declare is unconstrained on that resource. See Data model.
Priority	The relative importance of an order or a resource — lower is more important, and the value can be negative — used to make an acceptable-to-drop trade-off explicit under fleet pressure. See Soft constraints.
Route	The ordered sequence of stops a single resource performs within a plan’s solution — called a `tour` in the API response (`tours[]`, with `resourceId`, `distanceInKm`, `workingDuration`, and `wayPoints`). “Route” is the everyday term; `tour` is the field name you’ll see in payloads.
Route plan (or just “plan”)	The full request submitted for optimization — `resources`, `orders`, and any plan-level constraints or objectives — called `Plan` in the API. Submitting a plan doesn’t return a route directly; it returns a `solution` containing one route (tour) per resource. See Data model.
Solution	The engine’s best result found for a plan: which tour each resource runs, which stops couldn’t be placed, and the resulting objective values. Called `Solution` in the API. See How the optimization engine works.
Objective	One entry in a plan’s ordered `objectives` list, pursued in strict lexicographic priority — the first objective that separates two solutions decides which one wins. See Objectives and how they’re ranked.
Hard constraint	A constraint the engine never violates — a stop it can’t satisfy without breaking one is left unserved rather than the constraint being bent (`authorizedTimeWindows`, `requiredSkills`, capacities, and others). See Hard vs soft constraints.
Soft constraint	A constraint with a cost rather than a wall — the engine tries to satisfy it but accepts a violation if that’s what a higher-ranked objective requires (`preferredTimeWindows`, `preferredStopTags`, and others). See Hard vs soft constraints.
Delivery window	The time window during which a `delivery`-kind stop should or must be visited — `authorizedTimeWindows` (hard: outside of it, the stop can’t be planned at all) or `preferredTimeWindows` (soft: reachable outside it, at the cost of `minimizeDelay`). See Hard vs soft constraints and Data model.
Disruption	An event during execution that invalidates part of an already-computed solution and calls for a new one: a delay, a cancellation, or an urgent new order, typically. A disruption is handled by re-optimizing the affected plan, not by starting a new one — see Real-time re-optimization.
Re-optimization	Submitting an update to a plan that already has a solution, using the same `id` (the `version` is incremented, and the plan re-optimized, only if its content changed; a `PUT` identical to the stored plan changes nothing and isn’t billed). The engine treats this as “same problem, updated data” (the update still carries the complete plan, not only the changes): it repairs the previous solution, adjusting it just enough to be valid for the new data, then keeps improving from there, rather than searching from scratch. See How the optimization engine works.

API

Data model & glossary

Usage, limits & billing