Create and edit drivers

Maintain organisation-wide driver templates for planning across scenarios.

Before you start

Run these examples on a trusted server with TAROT_API_KEY set in its environment. Use X-Tarot-API-Key on every request. Never expose the key in client-side code, including browser or mobile app code. See Getting an API key.

Drivers are reusable planning templates

A driver belongs to an organisation and is available across its scenarios—not just the scenario currently open. Planners select which drivers to use for each scenario. Creating a driver does not automatically select it for every scenario.

Think of optimisation as rubber-stamping the selected driver template into a scenario-specific run: shift times, capacity, skills, route-end settings, contact details, and other defaults are copied when the run is created. A run also retains its driver association, but it is not a live view of all driver settings.

Editing a driver changes the reusable template for future planning; it does not automatically rewrite those copied fields on existing runs. Review already-planned runs separately in Tarot. A driver resource is also distinct from a login account: creating one does not create a Driver App user.

Find existing drivers

GET /v3/core/drivers?page=1&per_page=100

curl --fail-with-body -X GET "https://api.optimiser.app/v3/core/drivers?page=1&per_page=100" \
  -H "X-Tarot-API-Key: $TAROT_API_KEY"

Collection responses contain data, page, per_page, total_pages, and total_count, not a bare array. Process data, then request each subsequent page through total_pages, preserving your filters. Examples show the first page only.

Match your driver by uid and organisation, and retain its numeric id. Ensure you have the driver’s numeric ID from this list or the create-driver response. The edit examples assume it is available in the DRIVER_ID environment variable. A single driver can be retrieved with GET /v3/core/drivers/{driver_id}.

Create a driver

Replace organisation_id with your organisation’s numeric ID and use a stable, recognisable uid. Driver operations require the key’s role to have user-level access to that organisation.

Prepare a JSON request body like the following. The examples assume it is available in driver.json.

{
  "uid": "DRIVER-001",
  "organisation_id": 123,
  "shift_start": "08:00:00",
  "shift_end": "17:00:00",
  "location": {
    "address": "1 Martin Place, Sydney NSW 2000, Australia",
    "lat": -33.8679,
    "lon": 151.2073
  },
  "route_end": "start",
  "email": "driver@example.com",
  "speed_multiplier": 1.0
}

POST /v3/core/drivers

curl --fail-with-body -X POST "https://api.optimiser.app/v3/core/drivers" \
  -H "X-Tarot-API-Key: $TAROT_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @driver.json

HTTP 201 returns the created driver object. Save its id. Inspect existing drivers before repeating a create request; do not assume this endpoint upserts by uid.

Important driver fields

FieldMeaning
uid / organisation_idRequired driver identifier and owning organisation ID.
shift_start / shift_endShift times as HH:MM:SS in the planning timezone.
locationStart/depot location; provide accurate coordinates and an address.
route_end / end_locationroute_end is start (return to start), end_location (finish at the supplied end_location), or anywhere.
capacity / spec_typeCapacity expression and skill/compatibility values, aligned with your job constraints. Confirm the appropriate capacity format with your planners.
lunch_time / lunch_duration / lunch_latest_startBreak timing, duration in minutes, and latest start. Latest start must not precede lunch_time.
speed_multiplierPositive speed multiplier; 1.0 is the default.
email / phone_number / preferred_methodContact and dispatch preferences; configure alongside your platform dispatch workflow.
default_driver_user_id / default_vehicle_idOptional links to an existing driver user and vehicle accessible to the organisation; these do not create those resources.

See DriverSchema schema reference for all fields, including billing defaults and territories.

Edit an existing driver

Send only the fields you want to change. This example extends the shift and updates the contact email. The ID belongs in the URL; the request body need not repeat it.

Prepare a JSON request body containing your changes. The examples assume it is available in driver-update.json.

{
  "shift_end": "18:00:00",
  "email": "updated-driver@example.com"
}

PATCH /v3/core/drivers/{ID}

curl --fail-with-body -X PATCH "https://api.optimiser.app/v3/core/drivers/${DRIVER_ID}" \
  -H "X-Tarot-API-Key: $TAROT_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @driver-update.json

HTTP 200 returns the updated driver object. Confirm the changes and ask planners to review any affected future scenarios. Existing runs keep their copied settings unless separately changed.

Next, create scenarios and jobs to plan with your drivers.