OptimoRoute

Read how orders were completed, by order number, via GET /get_completion_details. The GET form, documented in the reference's own prose and measured live 2026-09-24: repeat `orderNo` once per order. It reaches only orders addressed by the number YOU assigned, and it cannot ask for customer feedback -- use the POST form for `id` lookups or for `includeCustomerFeedback`. Each order comes back with its own `success`, and an unknown one is reported as `ERR_ORD_NOT_FOUND` in the list rather than failing the call. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read whether a date's routes and customer notifications have been sent, via GET /get_dispatch_status. With no `date` it answers for the LIVE routes -- the ones most recently sent to drivers -- and reports which date those are. `includeRouteChanges` adds what has changed since the last send. This is the SEND status, not the delivery status: it says the routes went out, not that a driver opened them. It is also this connection's health check -- it takes no arguments, costs nothing and answers `success: true` for a working key (measured 2026-09-24), which is why the declared credential probe uses it. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read what drivers' mobile apps have reported, via GET /get_events. A CURSOR, NOT A SEARCH: call it with an empty `after_tag`, keep the `tag` from the reply, and pass that as `after_tag` next time to get only what has happened since. `remainingEvents` says how much is still queued. EVENTS CAN ARRIVE OUT OF ORDER -- a phone that was offline syncs when it reconnects, so a 9:00 completion can follow a 9:10 one -- and each event carries `unixTimestamp`, `utcTime` and `localTime` for the same moment, so order by the timestamp rather than by position. This is the live feed; 'Get order completion details' is the settled record. The reference's section titled 'Get Mobile Events' documents THIS path: `/get_mobile_events` is not a route at all (404, measured 2026-09-23). OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read orders by order number via GET /get_orders. The GET form of 'Get orders', documented in the reference's own prose and measured live 2026-09-24: repeat `orderNo` once per order. It reaches only orders addressed by the number YOU assigned -- use 'Get orders' (the POST form) when you hold OptimoRoute's `id` instead, or when you are mixing the two. Each requested order comes back with its own `success`, and one that does not exist is reported as `ERR_ORD_NOT_FOUND` in the list rather than failing the call. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Poll a running optimization via GET /get_planning_status. `planningId` is mandatory. `status` is a single letter -- N new, R running, C cancelled by the user, F finished, E error -- alongside `percentageComplete`. F means the plan is ready to read with 'Get planned routes'. A `planningId` the account does not know answers `ERR_JOB_NOT_FOUND`. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read the planned routes for one date via GET /get_routes. `date` is mandatory. Each route carries its driver, vehicle, distance, duration, loads and its ordered list of stops; the three `include*` flags add the encoded polyline, the start/end points and the dispatch status. Narrow to one driver or vehicle with `driverExternalId`, `driverSerial` or `vehicleRegistration`. A date with nothing planned answers `{"routes": [], "success": true}` -- an empty plan, not a failure. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read when and by whom ONE order is scheduled, via GET /get_scheduling_info. Address it with EITHER `orderNo` or `id`. `orderScheduled` is the answer: false means the order exists but is not on a route, which is not an error. An `orderNo` that matches more than one order answers `ERR_MULTIPLE_ORD_FOUND` -- pass the `id` to disambiguate. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Create, update or replace up to 500 orders in one call via POST /create_or_update_orders. Takes `orders`, a list of the same order objects 'Create or update one order' takes. NO GEOCODING HAPPENS HERE -- the vendor states it plainly -- so every location must already exist in the account or carry `latitude` and `longitude`; an address string alone will not resolve. Partial success is normal: the top-level `success` is true when AT LEAST ONE order succeeded, and each entry in the returned `orders` list carries its own `success` and `code`, so read the list rather than the flag. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Create, update, replace or merge ONE order via POST /create_order. `operation` is mandatory and chooses which: CREATE makes a new order, UPDATE changes an existing one, SYNC creates or replaces, MERGE creates or updates field by field. For anything but UPDATE, `date`, `type` (D delivery, P pickup, T task) and `location` are mandatory too, plus one of `orderNo` or `id`. THIS IS THE ONLY ORDER WRITE THAT GEOCODES AN ADDRESS -- the bulk call requires a location that already exists or explicit latitude/longitude. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Remove EVERY order and planned route for a date via POST /delete_all_orders -- and WITH NO `date`, EVERY ORDER AND ROUTE IN THE ACCOUNT. The vendor's own wording: 'If no date is set, all orders and routes are removed from the system.' `date` is optional in the contract and is the only thing bounding the blast radius, so omitting it is not a default, it is the widest possible call. No recycle bin, no undo. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Permanently remove ONE order via POST /delete_order. Addressed by `orderNo`, which is mandatory. A POST that DESTROYS: OptimoRoute offers no recycle bin and no undo for a deleted order, so absence is confirmed by asking for the order again, not by reading this reply. OptimoRoute normally refuses to delete an order that sits on a live route; `forceDelete: true` overrides that restriction, and the order is gone from the dispatched route as well. An order whose date is being optimised answers `ERR_OPT_RUNNING` with the `planningId` that is holding it. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Permanently remove up to 500 orders in one call via POST /delete_orders. Each order object carries EITHER `orderNo` (the identifier you assigned) OR `id` (the one OptimoRoute assigned); at most 500 per call. A POST that DESTROYS, with no recycle bin and no undo. TWO FLAGS WIDEN IT: `deleteMultiple: true` deletes EVERY order matching an ambiguous `orderNo` rather than refusing, and `forceDelete: true` deletes orders sitting on live routes. Partial success is normal -- read each entry's own `success` and `code`, not only the top-level flag. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read how up to 500 orders were completed, via POST /get_completion_details. Each order object carries EITHER `orderNo` (the identifier you assigned) OR `id` (the one OptimoRoute assigned); at most 500 per call. Each entry's `data` carries the completion `status` (success, failed, rejected, scheduled, on_route, servicing), the start and end times, the driver's form answers, signature and photo URLs, barcode scan results and the tracking URL. `includeCustomerFeedback: true` adds the customer's rating where the account has feedback configured. This is the settled record; 'Get driver app events' is the live feed. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Read up to 500 orders in one call via POST /get_orders. Each order object carries EITHER `orderNo` (the identifier you assigned) OR `id` (the one OptimoRoute assigned); at most 500 per call. The reply's top-level `success` is true when AT LEAST ONE order was retrieved, so it is not a per-order verdict: each entry in `orders` carries its own `success`, its `data` when found, and `ERR_ORD_NOT_FOUND` when not. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Find orders by date range or by identifier via POST /search_orders. At least one of `dateRange` (at most 35 days) or `orders` must be given. `orderStatus` filters by status, `includeOrderData` and `includeScheduleInformation` decide how much of each order comes back, and up to 500 orders are returned per page -- when more match, the reply carries an `after_tag` to pass back on the next call. This is the tool for 'which orders exist'; 'Get orders' is for orders you can already name. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Dispatch a date's planned routes to the drivers' mobile apps via POST /send_routes. `date` is mandatory. THIS IS THE CALL THAT REACHES PEOPLE: the routes it sends become the LIVE routes, drivers see them immediately, and `sendNotifications: true` also sends the account's configured customer notifications -- emails and text messages to the customers on those orders. Not flagged destructive because it destroys nothing, but it is not reversible by an API call either: a notification that has gone out has gone out. `ERR_NOTHING_TO_SEND` means the date has no unsent changes. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Start an optimization run for a date via POST /start_planning. `date` is mandatory (or `dateRange`, which overrides it, for weekly planning). THIS REPLACES THE PLAN: `startWith` and `lockType` decide how much of the existing schedule survives, and everything not locked is re-planned. The reply is a `planningId`, not a plan -- optimization runs asynchronously, so poll 'Get planning status' and read the result with 'Get planned routes'. One run per date: starting a second answers `ERR_OPT_RUNNING_FOR_DATE` and returns the id of the run already going. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Cancel a running optimization via POST /stop_planning. `planningId` is mandatory and is what 'Start planning' returned. Not destructive -- it stops a computation, and whatever plan existed before it started is what remains. `ERR_OPT_NOT_RUNNING` means the run had already finished or been cancelled. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Write completion details for up to 500 orders via POST /update_completion_details. Takes `updates`, each naming its order by `orderNo` or `id` and carrying the `data` to record -- the completion status, times and form answers a driver would otherwise have entered in the app. THIS OVERWRITES THE RECORD of what happened on a job; it is how an external system of record feeds its own proof-of-delivery back into OptimoRoute. Not flagged destructive (no order or route is removed), but it replaces completion data rather than appending to it. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Set ONE driver's availability, working hours, start and end locations and vehicle capacities for ONE date, via POST /update_driver_parameters. `date` and `externalId` are mandatory. THIS UNSCHEDULES WORK: the vendor states that any existing routes for that driver and date are unscheduled by the change, so the orders on them return to the unplanned pool and the date has to be re-planned. Changing a driver's parameters is therefore a planning action, not a profile edit. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Report ONE driver's position at ONE moment via POST /update_driver_status. The single-sample form of 'Update drivers' positions', for a tracker that pushes one fix at a time. NOT ON THE CURRENT REFERENCE PAGE -- it was documented in OptimoRoute's own v1.11 PDF and has since been dropped from the page, while the endpoint stays live. THE CONTRACT WAS MEASURED, FIELD BY FIELD, on 2026-09-24 against the live API, whose JSON Schema names each missing property in turn: ALL SIX of `externalId`, `datetime`, `latitude`, `longitude`, `speed` and `angle` are required, and the schema is CLOSED -- any other property is refused with `ERR_INVALID_PARAM_FORMAT`. `externalId` is the driver's external id from driver administration; an unknown one answers `ERR_DRIVER_NOT_FOUND`. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Set up to 500 driver/date parameter changes in one call via POST /update_drivers_parameters. Takes `updates`, a list where each entry names its `driver`, its `date` and the parameters to change. THIS UNSCHEDULES WORK for every driver and date it touches, exactly as the single-driver call does. Partial success is normal: the top-level `success` is true when at least one update worked, and each entry in the returned `updates` list carries its own verdict. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Report where drivers were, at given moments, via POST /update_drivers_positions. Takes `updates`, each naming a `driver` and a list of `positions`; at most one entry per driver per call. This is the feed for fleets whose tracking comes from a telematics box rather than the OptimoRoute driver app, and it is what live tracking and ETAs are computed from. Partial success is normal -- read each entry's own verdict. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.

Report ONE vehicle's position at ONE moment via POST /update_vehicle_status. The vehicle counterpart of 'Update a driver's position', for fleets that track the vehicle rather than the person. NOT ON THE CURRENT REFERENCE PAGE -- documented in OptimoRoute's own v1.11 PDF, dropped from the page since, still live. THE CONTRACT WAS MEASURED, FIELD BY FIELD, on 2026-09-24 and is IDENTICAL to the driver call's: all six of `externalId`, `datetime`, `latitude`, `longitude`, `speed` and `angle` are required and nothing else is accepted. Here `externalId` names the VEHICLE; an unknown one answers `ERR_VEH_NOT_FOUND`, which is how the two endpoints were told apart. OptimoRoute answers HTTP 200 to failures as well as successes and puts the verdict in the body's `success` flag with a `code`; Agentic Fabriq reads that envelope and turns a request-level failure into a real 4xx, so a result that reaches you is one OptimoRoute accepted.