Nominated Delivery Day on API Documentation

Dimension

Fri, 06 Mar 2026 00:00:00 +0000

Overview

Dimensions represent the measurable quantities in a model: time, distance, capacity, mass, weight, volume and so on. In the NDD model, the dimension configuration also defines the planning horizon through the weekLength and periodLength fields, which determine how many days are being planned across and how weeks are structured within that period.

Geocode

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A geocode represents a geographic coordinate using longitude and latitude in decimal degrees. Geocodes are used to position locations on the road network and are also returned as route segments in the solution response.

Applicable models

NDD ndd-cmibu6krtqja

Geocode

Schema definition

message Geocode {
  required float longitude = 1;
  required float latitude = 2;
}

Fields

longitude: The longitude of the coordinate in decimal degrees.
latitude: The latitude of the coordinate in decimal degrees.

Examples

A geocode for Dublin, Ireland:

longitude: -6.2603
latitude: 53.3498

Window

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A window defines a feasible interval on a dimension. Windows are most commonly used to represent time windows (e.g. a delivery must occur between 08:00 and 12:00) but can be applied to any dimension. Windows can be specified on location attributes, task attributes, and vehicle shift tasks.

Location

Fri, 06 Mar 2026 00:00:00 +0000

Overview

Locations represent the physical positions at which tasks are performed. Each location has a unique identifier, a geocode for positioning on the road network, and optional attributes that define dimensional properties such as service times or arrival/departure windows at the location level.

Applicable models

NDD ndd-cmibu6krtqja

Location

Schema definition

message Location {
  required string id = 1;
  optional Geocode geocode = 2;
  repeated Attribute attributes = 3;
}

Fields

id: A unique identifier for this location.
geocode: The geographic coordinates of this location, specified as a geocode. The geocode is used to position the location on the road network for distance and time matrix generation.
attributes: A list of location attributes which define dimensional properties at this location, such as service times or time windows.

Examples

A location with a geocode and a time window:

id: "depot-01"
geocode {
  longitude: -6.2603
  latitude: 53.3498
}
attributes {
  dimensionId: "time"
  arrivalWindows {
    start: 480
    end: 1020
  }
}

Profile

Fri, 06 Mar 2026 00:00:00 +0000

Overview

Profiles define the frequency and day-pattern constraints for periodic visits. Every job in the NDD model requires a profile, which is what distinguishes the NDD schema from the standard IVR7 model. Profiles control how many times a job must be visited within the planning period and, optionally, on which specific day patterns those visits may occur.

Job

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A job maps to a collection of tasks (e.g. a pickup and dropoff can be one job). All tasks within a job must be completed in the order specified. In the NDD model, each job also carries a profile which defines the visit frequency and day-pattern constraints. This is the key field that separates the NDD schema from the standard IVR7 job.

Vehicle

Fri, 06 Mar 2026 00:00:00 +0000

Overview

Vehicles represent the active resources in an NDD model. Unlike the standard IVR7 model where a vehicle has a single shift, the NDD model requires a vector of shifts defining the vehicle’s working hours for each day in the planning period. This allows the model to account for different start times, end times, or depot locations on different days.

Vehicle Class

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A vehicle class describes how a group of vehicles interacts with each dimension in the model. This includes linking vehicles to transit generators for distance and time matrices, and specifying coefficients that scale transit, task, and location quantities. Multiple vehicles may share the same vehicle class.

Vehicle Cost Class

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A vehicle cost class defines the cost coefficients applied to each dimension for a group of vehicles. This separates the physical behaviour of a vehicle (defined by its vehicle class) from its pricing, allowing different cost structures to be applied to vehicles that behave identically on the road network.

Transit Set

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A transit set provides a custom matrix of values between locations. Transit sets can be used to supply pre-computed distance or time matrices, or to define custom dimensional quantities for movements between locations. Transit sets are referenced by transit generators.

Applicable models

NDD ndd-cmibu6krtqja

TransitSet

Schema definition

message TransitSet {
  repeated TransitValue transits = 1;
}

Fields

transits: A list of transit values defining the pairwise quantities between locations.

Transit Value

A transit value defines a single origin-destination pair and the associated quantity.

Transit Generator

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A transit generator provides the mechanism to link a vehicle class to transit data (distance or time matrices). A transit generator can either reference a cached transit set from a previous request, or provide an inline transit set directly. When neither is provided, the API generates a transit set from the road network using the geocodes on the locations in the model.

Transit Rule

Fri, 06 Mar 2026 00:00:00 +0000

Overview

Transit rules define conditional activities that are triggered based on the cumulative state of a dimension during a vehicle’s route. A common use case is modelling mandatory rest breaks after a certain number of hours of driving. Transit rules are assigned to vehicle classes or individual vehicles.

Task Sequence

Fri, 06 Mar 2026 00:00:00 +0000

Overview

A task sequence defines a predefined ordering of tasks for a specific vehicle on a specific day. Task sequences are used to provide starting solutions for ReOptimise requests, to specify routes for Evaluate requests, or to recover a detailed schedule from a point on the Pareto frontier returned in the solution response.

Model

Fri, 06 Mar 2026 00:00:00 +0000

Overview

The model is the top-level object which contains all the defined input data for an NDD solve. It brings together the dimension configuration, locations, jobs (with profiles), vehicles (with multi-day shifts), vehicle classes, cost classes, transit rules, transit generators, and optional predefined task sequences.

Solve Request

Fri, 06 Mar 2026 00:00:00 +0000

Overview

The solve request houses the model and the action that should be performed on it. The NDD solve request supports an additional ExperimentalSolve type beyond the standard Optimise, Evaluate, and ReOptimise options.

Applicable models

NDD ndd-cmibu6krtqja

Endpoint

POST: https://api.icepack.ai/vehicle-router/solve/

Solve Request

Schema definition

message SolveRequest {
  optional Model model = 1;
  optional string modelID = 2;
  repeated TaskSequence routes = 3;
  optional SolveType solveType = 4 [default = Optimise];
}

Fields

model: The target model which should be solved (commonly specified). If not specified, the modelID field should be provided with a valid reference to an existing model.
modelID: A GUID which refers to a valid model which has recently been solved. Model data are stored in a hot cache for 24 hours after which they are deleted. If a modelID references a model which no longer exists, an error is returned.
routes: An optional list of task sequences specifying predefined routes. Used in conjunction with the modelID and the solve types Evaluate and ReOptimise. The task sequences specified here will override any task sequences defined within the model.
solveType: The solve type defining the target solver behaviour.

Notes

Either a complete model or a valid modelID should be specified.
Predefined routes are ignored for the Optimise solve type.
The typical NDD workflow involves two API calls: first an Optimise request which returns a Pareto frontier of compact solutions, then an Evaluate request using the task sequences from a chosen frontier point to recover the full solution detail.

Solve Request Solve Type

Schema definition

enum SolveType {
  Optimise = 0;
  Evaluate = 1;
  ReOptimise = 2;
  ExperimentalSolve = 3;
}

Fields

Optimise: Issues an Optimise request which finds a set of solutions forming a Pareto frontier. The solution response will contain a collection of compact solutions representing the tradeoff between competing objectives. Provided task sequences are ignored.
Evaluate: Issues an Evaluate request which evaluates the provided task sequences against the model. Returns a single solution instance with full route detail, stops, and dimensional evaluations. This is typically used to recover the detail of a point selected from the Pareto frontier.
ReOptimise: Issues a ReOptimise request which uses the provided task sequences as a starting solution and continues to optimise. If the provided solution is feasible, the result is guaranteed to be equal or better in cost.
ExperimentalSolve: Uses an experimental decomposition code-path. This may provide improved performance on certain problem structures but behaviour may change between API versions.

Solution Response

Fri, 06 Mar 2026 00:00:00 +0000

Overview

The NDD solution response has two tiers of structure. An initial Optimise request returns a Pareto frontier of compact solutions, each representing a different tradeoff between competing objectives (e.g. cost vs. balance). The user selects a point on the frontier and submits an Evaluate solve request to recover the full route detail as a solution instance.