Simeons Movers Manifest API
The API turns a current operating snapshot into proposed driver manifests. It can also check whether the movement legs for a proposed booking fit the available driver, lorry, Nugget, time-window, and HGV journey capacity.
The source platform remains the system of record. Requests are stateless: they do not create bookings, change authorised manifests, or store the submitted operating snapshot.
Integration operations
| Operation | Endpoint | Result |
|---|---|---|
| Generate driver manifests | POST /v1/manifests | A time-sequenced manifest for each assigned driver, plus any unscheduled movement legs. |
| Check booking availability | POST /v1/booking-checks | feasible, infeasible_proven, or unknown, with alternative windows when available. |
These are the only client integration operations in the public OpenAPI contract. Health checks, deployment readiness, and service administration are operated separately.
Booking and movement boundary
Simeons Movers presents customer-visible booking types such as storage, full removal, or return from storage. The source platform translates each booking into one or more atomic movement legs. This API schedules those legs and returns driver manifests.
For example, a storage booking may become a warehouse-to-property movement followed later by a property-to-warehouse movement. The booking remains one customer record; each movement leg is planned independently and retains its parent booking_id.
Planning boundary
Haladir obtains HGV journey data from PTV, runs the deterministic planner and Hexaly improvement model, and independently replays the result before returning it. The public request does not contain PTV credentials, map matrices, optimizer weights, or licence settings.
The current contract covers fresh manifest generation and booking-capacity checks. It does not yet accept work already in progress, explicit route holds, or authorised manifests that must be partially preserved during replanning.