API Reference
API Reference

The fleet consists of your drivers. Each driver is defined by their start_location and (optionally) an end_location.

"fleet": {
  "driver_1": {
    "start_location": {
      "id": "depot",
      "name": "800 Kingsway",
      "lat": 49.2553636,
      "lng": -123.0873365
    },
    "end_location": {
      "id": "depot",
      "name": "800 Kingsway",
      "lat": 49.2553636,
      "lng": -123.0873365
    },
    "shift_start": "8:00",
    "shift_end": "17:00",
    "min_visits": 14,
    "capacity": 10,
    "type": ["A", "B"],
    "strict_start": true,
    "breaks" : [
      {
        "id": "lunch",
        "start": "12:00",
        "end": "13:00"
      },
      {
        "id": "client call",
        "start": "15:00",
        "end": "15:30",
        "in_transit": true
      }
    ]
  },
  "driver_2": {
    "start_location": {
      "id": "depot",
      "name": "800 Kingsway",
      "lat": 49.2553636,
      "lng": -123.0873365
    },
    "end_location": {
      "id": "depot",
      "name": "800 Kingsway",
      "lat": 49.2553636,
      "lng": -123.0873365
    },
    "shift_start": "8:00",
    "shift_end": "17:00",
    "capacity": 5
  }
}
PROPERTYTYPEREQUIRED
start_locationLocation objectrequired
end_locationLocation objectoptional
shift_startString ("hh:mm")optional
shift_endString ("hh:mm")optional
capacityNumber (any unit)optional
typeString or Arrayoptional
speedString(faster, fast, normal(default), slow, very slow, bike) or Numberoptional
strict_startBooleanoptional
min_visitsNumberoptional
breaksArray of Objectsoptional

The end-location is optional and may be omitted. It may be useful in cases to have open-ended routes in some situations.

shift_start and shift_end specify when the driver starts driving and when he/she needs to be finished. If you have an end_location, then the shift_end means the latest time that the driver has to arrive there; otherwise it is the latest time that the driver can do their last job. Both parameters are optional. Without a shift_start, the algorithm will automatically infer the best time to depart, depending on your visits' time-windows.

capacity is an optional parameter to define the total capacity that can fit in the vehicle (using the same unit as the load for your visits). The algorithm will make sure that this capacity will not be exceeded.

📘

Capacity + loads

In order to use the capacity constraint, make sure that you also define the load parameters on the visits. If loads are not set, it is assumed that the visit does not take up any room in the capacity of the fleet.

If you'd like to use capacity as a limit of x number of orders, then use load: 1 for each visit.

📘

Multiple capacities

You may also specify multiple load and capacity parameters if you provide an object instead of a number. This is useful if you define your capacity across multiple dimensions, for example weight and volume:

"capacity": { 
  "weight": 1000,
  "volume": 200
}

You can specify your own dimensions as well. See load parameter on the Visits section for more examples.

Note that if you specify multiple capacities, for loads to fit, it has to fit across all dimensions. So if you have plenty of weight capacity left, but in terms of volume it's already full, then the load won't fit.

If you are using type restrictions on your visits, make sure you also define the same types for your vehicles in the type parameter. This value can be either a String — depicting a single type — or an Array of Strings for multiple types. Vehicles without any type will still be able to serve the visits that have no type restrictions.

speed: Not all your drivers are as experienced and may cruise the roads at different speeds. Use this parameter to specify the driver's speed. The default value for speed is normal or 1. Each step increases or decreases the vehicle speed by 25%, so for example very slow would describe a driver travelling at 50% of a normal driver's speed. For more control over the speed, you can also pass in a (decimal) number from 0.1 to 2. A speed of 0.1 would mean the vehicle is travelling at 10% speed while 2 means the vehicle is travelling at twice the speed.

📘

If your fleet consists of bikes, you may use bike as the speed parameter, which reduces the speed to 25% of a normal vehicle.

strict_start is a flag to force the departure time of a driver to be at shift_start. By default this flag is set to false, which means that the algorithm will attempt to delay the departure of a driver, if it results in reduced idle_time along the route. Do note that if strict_start is set to false and driver breaks are enabled, our routing algorithm will treat the problem as if you had sent strict_start: true.

min_visits is an optional parameter that allow you to specify a minimum number of visits that should be assigned to this vehicle. Specifying min_visits will override the global min_visits_per_vehicle parameter (see Options below). This is useful to balance the orders across your fleet when your drivers work different shift lengths.

📘

Breaks

You can specify one or more breaks for your drivers. This could be a lunch break, some personal errand, or even a pre-scheduled call your driver needs to take while transiting. It basically allows you to block off parts of your shift; Routific will optimize your stops around it.

breaks expects an array of objects. Each object requires an id, start and end times of the break, and you can optionally specify that the break can be taken in_transit – e.g. a call that you take in the car. Here's an example:

"breaks" : [
      {
        "id": "lunch",
        "start": "12:00",
        "end": "13:00",
      },
      {
        "id": "client call",
        "start": "15:00",
        "end": "15:30",
        "in_transit": true
      }
    ]

In the solution, a break in your schedule is returned as follows:

{
  id: "lunch",
  break: true,
  arrival_time: "12:11",
  finish_time: "13:00",
  start: "12:30",
  end: "13:00",
  in_transit: false
}

Note: Driver breaks are not supported on our /pdp and pdp-long endpoints.