Reference · built on requestConnectorFleet & telematics

DispatchTrack

Route plans, stop groups, stops, trucks, and exported routes from the DispatchTrack Planner API.

Request accessPricing ↗

About

The DispatchTrack Planner API is the route-planning interface of DispatchTrack. You load stops into stop groups, each with a delivery window, a service time, a priority from 0 to 9, a dispatch_center, and the items on board with their capacities. You define trucks with work hours, capacity_one and capacity_two, per-tour limits, and cost per kilometer or hour. A planner plan ties stop groups to trucks under a planner_setting. When a plan is exported, DispatchTrack POSTs one webhook per route with the vehicle, the ordered stops, and each stop's arrival_time.

An operator on Fibric reads the exported routes and the stop groups behind them, finds the stop that fell outside its window or the truck that is over its limit, and proposes the change for your approval.

This is a reference listing. It documents what Fibric would read from DispatchTrack and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Planner plans through GET /v1/planner_plans with planner_setting (min and max deliveries, laps), stop_group_ids, and truck_identifiers
  • Stop groups and stops through GET /v1/stop_groups/:id with identifier, address, coordinates, service_time, priority, capacities, items, contact, and tags
  • Trucks through GET /v1/trucks with start_place, end_place, start_work_time, end_work_time, capacities, max_transport_point_count_per_tour, and cost fields
  • Places through GET /v1/places, which name the dispatch centers stops and trucks refer to
  • Plan routes webhook: one POST per route on plan export with plan_id, route_id, vehicle.identifier, start_time, end_time, and stops
  • Per stop on the exported route: arrival_time and driving_period in seconds, service_time, and min_delivery_time and max_delivery_time in UTC
  • Index responses paged with meta.pages totals and first, next, prev, and last links

Proposed actions

  • Target capability: propose a stop group through POST /v1/stop_groups with stops, dispatch dates, delivery windows, items, and contact
  • Target capability: propose changing a stop's address, coordinates, service_time, priority, or dispatch_center through PUT /v1/stop_groups/:stop_group_id/stops/:id
  • Target capability: propose a truck through POST /v1/trucks with work hours, capacities, per-tour limits, and cost parameters
  • Target capability: propose a plan through POST /v1/planner_plans naming stop_groups_ids, trucks_ids, and a planner_setting
  • Target capability: propose a dispatch center through POST /v1/places with name, address, latitude, and longitude

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold the export when a truck is over its limit

    Count the stops per route in the Plan routes webhook against max_transport_point_count_per_tour and capacity_one on the truck. Propose moving the overflow into another stop group before dispatch.

    With Route Overflow, Field Dispatch

  • Resequence when a window moves

    When a stop's window_one_start changes, compare it with arrival_time on the exported route. Propose the PUT to the stop and a fresh plan for the planner to approve.

    With Route Resequence

  • Tell customers their arrival window

    Turn each stop's arrival_time and min_delivery_time and max_delivery_time into a customer notice keyed by the stop identifier, and queue it for approval.

    With ETA Notice

  • Book the dock from the route start

    Read start_time and end_time per route and the truck's start_place, then propose the loading slot at that dispatch center.

    With Dock Schedule

Requirements

  • A DispatchTrack Planner account with an API key from Settings -> ApiKeys
  • Places created first, because stop.dispatch_center and truck.start_place take a Place's name
  • Stop items with a code, a quantity above zero, and capacities that match the truck's capacity_one and capacity_two
  • A webhook URL registered through DispatchTrack support, with any custom header such as X-AUTH-TOKEN you want on the POST
  • A request quota increase from support@dispatchtrack.com if the lite tier's daily counts are too low
Authentication
A Basic Authorization header carrying base64 of api_key_name:api_key_secret, created under Settings -> ApiKeys in the DispatchTrack web interface, with Content-Type application/json on every request.

Limits

  • The lite tier allows 1,000 GET requests a day and 100 each of POST, PUT, and DELETE; over the limit returns 429
  • Index endpoints return 30 resources a page by default and at most 100 with per_page
  • The only documented webhook is Plan routes, sent when a plan is exported; there is no stop-completion or driver-status event
  • Route times arrive as seconds since the start of the day; delivery windows arrive as UTC timestamps

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request DispatchTrack ↗

Questions and answers

How do I authenticate to the Planner API?
Create an API key under Settings -> ApiKeys in the web interface. Encode api_key_name:api_key_secret in base64 and send it as a Basic Authorization header with Content-Type application/json. A missing or wrong key returns 401.
What does the Plan routes webhook contain?
One POST per route when a plan is exported: plan_id, route_id, account_id, user_id, start_date, end_date, start_time and end_time in seconds since midnight, vehicle.identifier, and a stops array with stop_group_id, stop_id, identifier, coordinates, address, arrival_time, driving_period, service_time, and delivery_times.
What request limits apply?
The lite version allows 1,000 GET, 100 POST, 100 PUT, and 100 DELETE requests a day. Every response carries headers with current usage and the maximum for that resource and action. Exceeding a limit returns 429 Exceeded request limit.
Ask about DispatchTrack

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with DispatchTrack through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy