What route optimization APIs can really model
Eleven route optimization APIs tested against 149 business constraints drawn from real operations, across eight sectors. One question per cell: is the constraint explicitly documented and enabled through the API? More than 1,600 evaluations, all traceable down to the source-file line.
How these figures are computed
Public documentation only. A constraint counts when it is explicitly documented and enabled through the API. Two methodological points are worth reading before the numbers.
Public documentation
Only the public documentation of each API counts as proof. For every constraint Kardinal covers, the implementation proof is provided in the explorer.
149 constraints, 8 sectors
149 business rules across 11 functional families. 21 belong to a generic core, 128 are tied to one of seven sectors: parcel, retail, bulky, cold-chain, long distance, waste, field services.
Three states, not two
Each cell is covered, partial or absent. Partial counts as half a constraint, which avoids treating an incomplete implementation as a plain absence.
11 engines
Two methodological points to keep in mind
The reference set is not neutral. It gathers business constraints documented and met in real operations. Kardinal covers 139 of 149, or 93.3%, and provides the implementation proof for each of those 139. The figure to read is not that score, but the gap between the other APIs and a catalogue of real business needs.
No popularity filter was applied. A constraint enters the scope because it matches a documented operational need, not because several vendors handle it. Ten of them are covered by none of the ten competing APIs and therefore mechanically pull every score down.
Overall ranking across the 149 constraints
The solid bar measures fully covered constraints, the hatched band partial coverage. Kardinal leads at 93.3%; no competing engine reaches three quarters of the reference set.
Calculation: (covered + 0.5 × partial) / 149.
What the ranking shows
Coverage by functional family
The 149 constraints split into 11 families. This is where profiles diverge: an engine can be strong on time windows and absent on route structure.
Reading: share of the family's constraints covered by the engine, partial counted 0.5. The number of constraints in each family is shown under its name. A 2-constraint family only moves in 25% steps.
Coverage by sector
Each constraint carries a scope: generic, or tied to a sector. Two readings are possible, and they do not tell the same story.
The market's blind spots
Ten constraints in the reference set are covered, even partially, by none of the ten competing engines. Kardinal covers all ten. Almost all of them concern operations where a route is not a simple sequence of deliveries.
Covered by a single competitor
Covered by all ten competitors
Explorer of the 149 constraints
The entire source file, row by row. Click a row to read the original definition and the Kardinal-side implementation proof.
Limits and traceability
What this benchmark measures, what it does not, and what to know before using it to pick a tool.
Coverage, not performance
No measure of compute speed, solution quality or cost. An engine that models a constraint may solve it badly; an engine that does not model it cannot solve it at all.
Documentation, not product
A capability that exists but is not publicly documented is counted absent. The result measures documented coverage at a given date, not everything an engine can do.