TransportRequest and TransportRequestAccept

The entity types TransportRequest and TransportRequestAccept are used in the publishing of a request for transportation on the shipper side, and optionally reporting the desire to accept that transport on the carrier side.

TransportRequest and TransportRequestAccept

This is an optional pre-step prior to actually ordering a shipment, that is done with the entity TransportInstruction.

The actors are typically a shipper and a carrier:

  • The shipper publishes the request for the transportation of something by creating a TransportRequest entity (e.g. using an ERP or transport administration system). Provided the IoL data sharing is setup properly, the carriers that have been selected to see the published requirement will be notified using a webhook.
  • The carrier(s) to which the transportation request was published will receive a web hook notification, and can optionally chose to respond with a TransportRequestAccept entity, to notify the shipper they are prepared to handle the shipment under the published circumstances.

When a shipper publishes the need to send something, the TransportRequest entity contains basic information about the shipment, such as:

  • Size
  • Weight
  • Pick-up address
  • Delivery address
  • Etc.

Additionally, it contains optional conditions, such as:

  • Earliest pick-up time
  • Latest delivery time
  • Maximum accepted price
  • Etc

Carriers who are prepared to transport the shipment respond with a TransportRequestAccept entity, which contains information like:

  • Estimated pick-up time
  • Estimated delivery-time
  • Carrier product used to transport the shipment
  • Price
  • Etc

Zero, one or many carriers may show interest in the shipment, but it is optional for them to do so. If they are not interested in the shipment, they have to do nothing. The fact a carrier reply to the transport request affirmative, does not mean the shipper chooses to order the shipment from that carrier.

Since it may happen that no carrier wants to do the shipment, the software on the shipper side should have a timeout and handle the situation when no-one wanted the shipment. Examples of this can be to retract the transportation request, and/or automatically use a fallback carrier.

It may also happen that one or more carriers showed interest in the shipment, and in such case, the shipper must chose which one to use for this transport by selecting the desired carrier out of the ones who responded (this can be done either manually using a GUI or automatically by software logic, in the ERP or transport administration system).

The TransportRequest and TransportRequestAccept concept do not include actually ordering the shipment from the selected carrier. This is done using the traditional method with TransportInstructions by the shipper’s software (typically an ERP or transport administration system).

The transport request concept is only an optional pre-step to find out what carrier(s) are interested in a particular shipment. The shipper should chose one of them and order that shipment using the traditional procedure thereafter.

API Reference information is here. Also study the TransportRequest and the TransportRequestAccept data schemas.