Order Book provides ready-to-run domain-specific logistic data governance for your route optimization.
- Upsert a Delivery by business id for a given TransportRequest
Get a Delivery by business id for a given TransportRequest
Delete an Delivery by business id for a given TransportRequest
Get a Delivery by business id
Upsert a Delivery by business Id
Delete a Delivery with specified business Id
Upsert a Delivery by busi...
Conundra Order Book API (1.6.1)
Download OpenAPI description
Overview
Servers
Mock server
https://developer.conundra.eu/_mock/apis/order-book/order-book-api
Order Book API Production
https://api.conundra.eu/orderbook/v1
- Mock serverhttps://developer.conundra.eu/_mock/apis/order-book/order-book-api/transport-requests/{business_id}/orders/deliveries/{order_id}
- Order Book API Productionhttps://api.conundra.eu/orderbook/v1/transport-requests/{business_id}/orders/deliveries/{order_id}
OK
An optional category for the Order, represented by its code. Defining a category for your Order can help in easy retrieval of the information in the user interface.
Conditionals can be targeted to Orders with a specific category, allowing the planner to create business rules for sets of Orders.
Example: "orderCategoryA"
A freeform text description, providing additional details that might be of use for a planner.
Example: "a description"
Required capacity on the executor of this Order. The executor will need to be able to fulfill all capacities specified on this Order in order to execute it.
Characterization of a capacity, representing the dimension in which this Capacity is expressed.
Default "volume"
Enum"volume""weight""loadingMeters""capacity1""capacity2""capacity3""capacity4""capacity5"
Boolean flag signaling the optimization that this order must be executed. If this flag is not provided the order is considered optional and an outsourcing_cost needs to be provided.
Default false
Example: true
Requirements and constraints that this order enforces of its executor. These properties help the optimization engine in determining which executors could be used for this Order.
Orders are handled last-in, first-out (LIFO) within an optimization. Specifying LIFO-groups will limit this behaviour to only those orders within the same LIFO group.
An order can be a part of multiple LIFO groups, which will result in the LIFO-constraint being applied within each LIFO group it is a part of.
Example: ["lifo_group"]
A fictional cost for not planning this order in an optimization. This allows the optimization engine to weigh the costs of executing the order versus outsourcing it to a (potentially fictitious) third party.
Example: 0
Custom data allows you te enrich an Order with relevant information for the planner that is not part of the Order Book domain. Custom data properties will be available on the distinct activities (Pickup and/or Delivery) of this Order in the planning context. This allows you to define a property once and have it available on both parts of a PickupDelivery Order.
When a custom data key is duplicated on the activity-level, it will override the value defined on the Order level.
The plan group this Order belongs to. Plan groups signify the group of orders that are supposed to be planned together.
Example: "a plan group"
Properties specific to the activity that needs to be executed for fulfilling this order. In case of a PickupDelivery Order, these are two separate activities with their own settings.
A known Location in Order Book at which this activity occurs. This allows reusing the information present on the Location, such as opening hours, addresses requirements... Using a site_location also allows you to target sets of Orders based on a shared Location reference in a Conditional. Combining the Order properties with those of the linked Location can be fine-tuned using the combination strategies on relevant properties.
Mutually exclusive with visit_location.
An ad-hoc address at which this Order needs to be executed. When using a visit_location either address information should be present, or otherwise a geo point. When no geo_point is provided the address will be resolved by our geocoding service. The resolved information is read only (ie: only available in a response).
Mutually exclusive with site_location.
The time that needs to be taken into account for stopping at the Order's location.
The duration required for executing this activity in the order.
Needs to be an ISO-formatted Duration, see wikipedia ISO-8601 and RFC-3339
The sequence of this activity of the Order within a Route.
Note: The sequence is applied to a route, not to trips within a route.
Example: 1
Supports two ways to specify when an order can be delivered:
windowedintervals are used in conjunction with a (site) Location's (planning) time windows or Conditionals. The windowed intervals will be limited to the smallest common intersection between all applicable time windows from these.absoluteintervals are absolute date times that will be used to plan the order.
Using both windowed and absolute intervals in conjunction can solve many complicated cases, especially when taking the flexibility of Conditionals into account.
At least one timerange is required, either absolute or windowed.
A set of date-time intervals within which this activity of the Order can be executed.
Absolute timeframes will always be retained on the Order after consolidation.
This property can be used to differentiate between orders visually. The orders within a planning will be shown in this color.
The color can be provided both as a CSS color name or using a hexadecimal color code (eg: #123DEF).
Example: "red"
Labels can be used for identifying sets of Orders. When starting an optimization, labels can be used for filtering the Order space and limiting the optimization to specific subsets.
Labels can also be used as filters in select Order Book features or Constraint Management.
Example: ["labelA"]
Custom data allows you te enrich an Order with relevant information for the planner that is not part of the Order Book domain. Custom data properties defined on this activity of an Order will be available in the planning context.
Keys defined on this level will override any custom data that is defined on other entities or properties.
Response
application/json
{ "order": { "business_id": "orderA", "order_category": "orderCategoryA", "description": "a description", "capacities": [ … ], "mandatory": true, "requirements": { … }, "lifo_groups": [ … ], "outsourcing_cost": 0, "custom_data": { … }, "plan_group": "a plan group", "client": "companyId" }, "delivery": { "site_location": { … }, "visit_location": { … }, "stop_time": { … }, "service_time": "PT5M", "sequence": 1, "time_frame": { … }, "color": "red", "labels": [ … ], "custom_data": { … } } }
Headers
Bodyapplication/jsonThe RFC7240 Prefer header indicates that a particular server behavior is preferred by the client but is not required for successful completion of the request (see RFC 7240).
The following behavior is supported by this API:
- return=<minimal|representation> is used to suggest the server to return using status code 204 without a resource in the response body (minimal) or using status codes 200 or 201 with the resource in the response body on success (representation).
An optional category for the Order, represented by its code. Defining a category for your Order can help in easy retrieval of the information in the user interface.
Conditionals can be targeted to Orders with a specific category, allowing the planner to create business rules for sets of Orders.
Example: "orderCategoryA"
A freeform text description, providing additional details that might be of use for a planner.
Example: "a description"
Required capacity on the executor of this Order. The executor will need to be able to fulfill all capacities specified on this Order in order to execute it.
Characterization of a capacity, representing the dimension in which this Capacity is expressed.
Default "volume"
Enum"volume""weight""loadingMeters""capacity1""capacity2""capacity3""capacity4""capacity5"
Boolean flag signaling the optimization that this order must be executed. If this flag is not provided the order is considered optional and an outsourcing_cost needs to be provided.
Default false
Example: true
Requirements and constraints that this order enforces of its executor. These properties help the optimization engine in determining which executors could be used for this Order.
Orders are handled last-in, first-out (LIFO) within an optimization. Specifying LIFO-groups will limit this behaviour to only those orders within the same LIFO group.
An order can be a part of multiple LIFO groups, which will result in the LIFO-constraint being applied within each LIFO group it is a part of.
Example: ["lifo_group"]
A fictional cost for not planning this order in an optimization. This allows the optimization engine to weigh the costs of executing the order versus outsourcing it to a (potentially fictitious) third party.
Example: 0
Custom data allows you te enrich an Order with relevant information for the planner that is not part of the Order Book domain. Custom data properties will be available on the distinct activities (Pickup and/or Delivery) of this Order in the planning context. This allows you to define a property once and have it available on both parts of a PickupDelivery Order.
When a custom data key is duplicated on the activity-level, it will override the value defined on the Order level.
The plan group this Order belongs to. Plan groups signify the group of orders that are supposed to be planned together.
Example: "a plan group"
Properties specific to the activity that needs to be executed for fulfilling this order. In case of a PickupDelivery Order, these are two separate activities with their own settings.
A known Location in Order Book at which this activity occurs. This allows reusing the information present on the Location, such as opening hours, addresses requirements... Using a site_location also allows you to target sets of Orders based on a shared Location reference in a Conditional. Combining the Order properties with those of the linked Location can be fine-tuned using the combination strategies on relevant properties.
Mutually exclusive with visit_location.
An ad-hoc address at which this Order needs to be executed. When using a visit_location either address information should be present, or otherwise a geo point. When no geo_point is provided the address will be resolved by our geocoding service. The resolved information is read only (ie: only available in a response).
Mutually exclusive with site_location.
The time that needs to be taken into account for stopping at the Order's location.
The duration required for executing this activity in the order.
Needs to be an ISO-formatted Duration, see wikipedia ISO-8601 and RFC-3339
The sequence of this activity of the Order within a Route.
Note: The sequence is applied to a route, not to trips within a route.
Example: 1
Supports two ways to specify when an order can be delivered:
windowedintervals are used in conjunction with a (site) Location's (planning) time windows or Conditionals. The windowed intervals will be limited to the smallest common intersection between all applicable time windows from these.absoluteintervals are absolute date times that will be used to plan the order.
Using both windowed and absolute intervals in conjunction can solve many complicated cases, especially when taking the flexibility of Conditionals into account.
At least one timerange is required, either absolute or windowed.
A set of date-time intervals within which this activity of the Order can be executed.
Absolute timeframes will always be retained on the Order after consolidation.
This property can be used to differentiate between orders visually. The orders within a planning will be shown in this color.
The color can be provided both as a CSS color name or using a hexadecimal color code (eg: #123DEF).
Example: "red"
Labels can be used for identifying sets of Orders. When starting an optimization, labels can be used for filtering the Order space and limiting the optimization to specific subsets.
Labels can also be used as filters in select Order Book features or Constraint Management.
Example: ["labelA"]
Custom data allows you te enrich an Order with relevant information for the planner that is not part of the Order Book domain. Custom data properties defined on this activity of an Order will be available in the planning context.
Keys defined on this level will override any custom data that is defined on other entities or properties.
- Mock serverhttps://developer.conundra.eu/_mock/apis/order-book/order-book-api/transport-requests/{business_id}/orders/deliveries/{order_id}
- Order Book API Productionhttps://api.conundra.eu/orderbook/v1/transport-requests/{business_id}/orders/deliveries/{order_id}
Order updated
Response body contains updated Order
Bodyapplication/json
General order properties. In case of a pickupDelivery Order, these properties are shared between both the pickup and delivery activities.
An optional category for the Order, represented by its code. Defining a category for your Order can help in easy retrieval of the information in the user interface.
Conditionals can be targeted to Orders with a specific category, allowing the planner to create business rules for sets of Orders.
Example: "orderCategoryA"
A freeform text description, providing additional details that might be of use for a planner.
Example: "a description"
Required capacity on the executor of this Order. The executor will need to be able to fulfill all capacities specified on this Order in order to execute it.
Characterization of a capacity, representing the dimension in which this Capacity is expressed.
Default "volume"
Enum"volume""weight""loadingMeters""capacity1""capacity2""capacity3""capacity4""capacity5"
Boolean flag signaling the optimization that this order must be executed. If this flag is not provided, an outsourcing_cost needs to be provided.
Example: true
Requirements and constraints that this order enforces of its executor. These properties help the optimization engine in determining which executors could be used for this Order.
Orders are handled last-in, first-out (LIFO) within an optimization. Specifying LIFO-groups will limit this behaviour to only those orders within the same LIFO group.
An order can be a part of multiple LIFO groups, which will result in the LIFO-constraint being applied within each LIFO group it is a part of.
Example: ["lifo_group"]
A fictional cost for not planning this order in an optimization. This allows the optimization engine to weigh the costs of executing the order versus outsourcing it to a (potentially fictitious) third party.
Example: 0
Custom data allows you te enrich an Order with relevant information for the planner that is not part of the Order Book domain. Custom data properties will be available on the distinct activities (Pickup and/or Delivery) of this Order in the planning context. This allows you to define a property once and have it available on both parts of a PickupDelivery Order.
When a custom data key is duplicated on the activity-level, it will override the value defined on the Order level.
Properties specific to the activity that needs to be executed for fulfilling this order. In case of a PickupDelivery Order, these are two separate activities with their own settings.
A known Location in Order Book at which this activity occurs. This allows reusing the information present on the Location, such as opening hours, addresses requirements... Using a site_location also allows you to target sets of Orders based on a shared Location reference in a Conditional. Combining the Order properties with those of the linked Location can be fine-tuned using the combination strategies on relevant properties.
Mutually exclusive with visit_location.
An ad-hoc address at which this Order needs to be executed. When using a visit_location either address information should be present, or otherwise a geo point. When no geo_point is provided the address will be resolved by our geocoding service. The resolved information is read only (ie: only available in a response).
Mutually exclusive with site_location.
The time that needs to be taken into account for stopping at the Order's location.
The duration required for executing this activity in the order.
Needs to be an ISO-formatted Duration, see wikipedia ISO-8601 and RFC-3339
The sequence of this activity of the Order within a Route.
Note: The sequence is applied to a route, not to trips within a route.
Example: 1
Supports two ways to specify when an order can be delivered:
windowedintervals are used in conjunction with a (site) Location's (planning) time windows or Conditionals. The windowed intervals will be limited to the smallest common intersection between all applicable time windows from these.absoluteintervals are absolute date times that will be used to plan the order.
Using both windowed and absolute intervals in conjunction can solve many complicated cases, especially when taking the flexibility of Conditionals into account.
At least one timerange is required, either absolute or windowed.
A set of date-time intervals within which this activity of the Order can be executed.
Absolute timeframes will always be retained on the Order after consolidation.
This property can be used to differentiate between orders visually. The orders within a planning will be shown in this color.
The color can be provided both as a CSS color name or using a hexadecimal color code (eg: #123DEF).
Example: "red"
Labels can be used for identifying sets of Orders. When starting an optimization, labels can be used for filtering the Order space and limiting the optimization to specific subsets.
Labels can also be used as filters in select Order Book features or Constraint Management.
Example: ["labelA"]
Custom data allows you te enrich an Order with relevant information for the planner that is not part of the Order Book domain. Custom data properties defined on this activity of an Order will be available in the planning context.
Keys defined on this level will override any custom data that is defined on other entities or properties.
Response
application/json
{ "order": { "business_id": "orderA", "order_category": "orderCategoryA", "description": "a description", "capacities": [ … ], "mandatory": true, "requirements": { … }, "lifo_groups": [ … ], "outsourcing_cost": 0, "custom_data": { … }, "plan_group": "a plan group" }, "delivery": { "site_location": { … }, "visit_location": { … }, "stop_time": { … }, "service_time": "PT5M", "sequence": 1, "time_frame": { … }, "color": "red", "labels": [ … ], "custom_data": { … } } }
- Mock serverhttps://developer.conundra.eu/_mock/apis/order-book/order-book-api/transport-requests/{business_id}/orders/deliveries/{order_id}
- Order Book API Productionhttps://api.conundra.eu/orderbook/v1/transport-requests/{business_id}/orders/deliveries/{order_id}
Locations
Locations can be managed separately in Order Book, which allows the user to capture their related business rules in a reusable manner. This is especially valuable in business cases where a select set of Locations is reused across many orders.
Typical use cases include capturing regular opening hours or requirements tied to a specific Location.
Operations