Skip to content

Conundra Order Book API (1.6.1)

Order Book provides ready-to-run domain-specific logistic data governance for your route optimization.

Download OpenAPI description
Servers
Mock server
https://developer.conundra.eu/_mock/apis/order-book/order-book-api
Order Book API Production
https://api.conundra.eu/orderbook/v1

Health check

Miscellaneous endpoints for general API functionality

Operations

Pickup Orders

Pickup orders represent an order where the executor needs to pick up cargo at a certain stop.

Operations

Delivery Orders

Delivery orders represent an order where the executor needs to drop off cargo at a certain stop.

Operations

PickupDelivery Orders

PickupDelivery orders represent an order where the executor needs to pick up cargo at a certain stop and deliver it at another stop.

Operations

Consolidated Orders

Orders are being consolidated by the application to enrich them with captured domain knowledge through Conditionals and/or Locations. These endpoints provide insights into and discoverability of the results of this consolidation.

Operations

Category Management

[EXPERIMENTAL] Endpoints for managing Categories.

Experimental Status: These endpoints have an experimental status since their complexity was impacted by a removed feature. We intend at the very least to vastly simplify these endpoints by removing the code-subresource.

Operations

Transport Requests

Transport Requests can be used to group Orders that share some administrative context. They can serve as a way of targeting Orders through conditionals, by providing context on the client companies for which those orders are being executed.

Operations

Companies

Companies can be managed in Order Book and used as clients for Transport Requests. This allows you to target Conditionals to Orders contained within Transport Requests for select clients.

Operations

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

Upsert a location with specified business Id

Request

Create of update a location.

The caller is responsible for providing a unique business id for each Location to retain consistency. If a call is made using an unknown business id, a new Location will be created, otherwise an update will be applied to the existing Location. Locations are versioned and the ETag-header will represent the type of operation that was executed. Conversely, adding an If-Match header to requests can protect the caller against unintended operations by acting as an optimistic lock.

Security
clientCredentials
Path
business_idstring^[a-zA-Z0-9.~\-_]{1,512}$required

The business identifier of an entity instance

Headers
If-Matchstring

weak Etag as optimistic locking check

PreferArray of strings

The 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).
Bodyapplication/jsonrequired
business_idstring^[a-zA-Z0-9.~\-_]{1,512}$required

Unique reference id

Example: "locationA"
location_categorystring

An optional category for the Locations, represented by its code. Defining a category for your Location can help in easy retrieval of the information through the search-endpoints or in the user interface.

A category will also allow you to target Conditionals to Orders which are tied to a Location with specific categories.

Example: "locationCategoryA"
namestring

An optional name that helps in identifying the Location.

Example: "locationName"
descriptionstring

A freeform text description of the Location, providing additional details that might be of use for a planner.

Example: "locationDescription"
commentstring

A freeform text field for adding comments to a Location.

Example: "locationComment"
addressobject(GeoAddress)required

The main, physical address for this Location. This address as mandatory for creating/updating a Location.

address_linestring

Optional address line representing the street address (optionally including house number, box, ...)

Example: "Voordries 41"
citystringrequired

The name of the locality. Mandatory if no geo point is provided.

Example: "Oosterzele"
zip_codestringrequired

The uniquely identifying code of this locality. Mandatory if no geo point is provided.

Example: "9860"
country_codestring(CountryCode)^[A-Z]{2}$required

An ISO3166-1 alpha-2 two letter country code. Mandatory if no geo point is provided.

geo_pointobject(GeoPoint)

A The geo point is optional, if and only if all the mandatory address fields are supplied. When no geo point is provided, a geocoding call will determine the geo point using the provided textual address fields. (See resolved address for more information.)

Adding a geo point allows you to retain full control of the data that will be used in your planning.

planning_addressobject(GeoAddress)

The planning address allows you to override the address on a Location. A typical use case for this would be to provide the official address of a retail location in the address field, but specifying a loading dock in a back alley using the planning address.

stop_timestring(IsoDuration)

The stop time to be applied when visiting this Location.

Must be specified as a valid ISO Duration (see wikipedia ISO-8601 and RFC-3339). Must be non negative.

requirementsobject(Requirements)

Requirements that have to be fulfilled by the executor of an order at this location.

time_windowobject(TimeWindows)

A collection of TimeWindows, defining when this location can be visited. This can be used to restrict an Order's windowed timeframes. If this property is not provided, we consider the location open 24/7.

planning_time_windowobject(TimeWindows)

Planning time windows allow you to specify a different set of time windows for use in the planning, and follow the same format as the time_window property. A typical use case for this would be to specify different delivery windows for a retail location (eg: you can deliver order before the regular opening hours of the retail location) while still providing the information about the regular opening hours (eg: a planner can still determine whether he would be able to contact anyone at the location during their regular opening hours).

If no planning time windows are specified, the regular time windows will be used for planning.

custom_dataobject(CustomData)

Custom data allows you te enrich a Location with relevant information for the planner that is not part of the Order Book domain.

Custom Data on a Location will be inherited by Orders linked to this Location. When a key is duplicated on the Order, the Order will retain its value for this key.

etagstring(Etag)

Must match header if provided on request.

Responses

Indicates the locations is created or updated.

The response body contains the location, since Prefer is set to return=representation.

Headers
ETagstring

weak Etag (ex W/<etag_value>) which contains the (updated) version of the entity

Preference-Appliedstring

to indicate whether a preference has been applied. (ex Preference-Applied: return=representation)

Bodyapplication/json
dataobject(Location)

A location has an address and timewindows representing opening hours.

An alternative address and/or timewindows to be used for planning can be specified. When planning address and/or timewindows are specified the originals are only there for information purposes.

An address item can consist of an address and/or geo coordinates. The resolved version will be resolved based on the geo coordinates or the address (not both). The resolved version will be available when reading to make out what the original geo coordinates in the routing service are.

Response
application/json
{ "data": { "business_id": "locationA", "location_category": "locationCategoryA", "name": "locationName", "description": "locationDescription", "comment": "locationComment", "address": {}, "planning_address": {}, "stop_time": "PT5M", "requirements": {}, "time_window": {}, "planning_time_window": {}, "custom_data": {}, "etag": "W/\"1\"" } }

Delete a location with specified business id.

Request

This endpoint allows you to delete a location.

Locations can only be deleted if they are no longer in use by future orders or conditionals.

Security
clientCredentials
Path
business_idstring^[a-zA-Z0-9.~\-_]{1,512}$required

The business identifier of an entity instance

Headers
If-Matchstring

weak Etag as optimistic locking check

Responses

Deletion has succeeded, but body is empty

Response
No content

Conditionals

Conditionals allow you to capture business rules in Order Book. You can target Orders based on several attributes or create time-based rules, and apply mutations to this order set enriching for your optimization.

Operations

Partial Routes [EXPERIMENTAL]

[EXPERIMENTAL] [UNDER DEVELOPMENT] Endpoints for managing preplanned PartialRoutes.

Operations