Order management
Order is the main object used in a load delivery flow. The regular flow starts with order creation. When an order is ready to dispatch, you send a load offer to Carrier TMS (CTMS). A carrier who receives the load offer accepts it and then picks up and delivers the load to its destination. All order status changes by carrier are automatically synchronized with the corresponding order in STMS.
The flow described above is a regular flow. However, sometimes you may want to update the order status manually before the carrier. For example, you may know that the order has already been picked up or delivered, but the driver hasn’t updated the order status yet. In such cases, you can change the order status manually. Later the carrier can update the order status, and the flow will continue as usual. This flow is called semi-manual flow.
Finally, there is a third type of flow called fully manual flow. In fully manual flow, you don’t send a load offer to Carrier TMS. Instead, you assign the order directly to a carrier and change the order status all by yourself. You can even create a new carrier profile inside STMS and assign orders to it. If the carrier exists in Carrier TMS, the order still won’t be synchronized. The fully manual flow’s purpose is to store historical orders created outside of STMS or orders delivered by carriers who don’t use Carrier TMS. Normally you don’t want to use the fully manual.
Note
Notice that many endpoints described here require object GUID (e.g., order, offer, carrier, etc.). You should store these GUIDs in your system to be able to use them. Also, you may want to subscribe to events that happened in STMS using webhooks. Webhooks allow implementing complex 2-way synchronization between STMS and external system. Refer to webhooks documentation for more details.
Table of Contents
- Table of Contents
- Creating an order
- Updating an order
- Sending a load offer
- Cancel a load offer
- Fetching all offers
- Manual order status change
- Rollback manually changed status
- Canceling an order
- Archiving an order
Creating an order
You can create order using the following endpoint
|
|
To create an order only number
field is required. However there are other required fields that will be needed for posting the order to Super Loadboard. Detailed description of order fields can be found in API reference for the endpoint.
Customer contact
The customer field stores the contact information of the load’s owner. If you want to link this customer contact with the customer profile in STMS, you can specify the customer’s GUID in counterparty_guid
field. This allows uniquely identify the customer. If the customer has access to the customer portal, she can monitor the load’s status directly in the system. If you specified customer GUID in counterparty_guid
and omitted all other information, all contact information will be automatically filled by the system. If the customer doesn’t exist in the system and you want to save its profile to use it in other loads, you can set save_as_new
to true
.
Pickup and delivery
Pickup and delivery fields contain information about the origin and destination of the load. The pickup scheduled date should be earlier than the delivery scheduled date. If you use the estimated date type, you can also specify pickup and delivery end dates. These date ranges are used in Super Loadboard for load requests. If the preferred carrier picks a date outside of these ranges, he can’t instantly book a load and only request it. Refer to Super Loadboard documentation for further information about load requests.
As with customer contact information, you set counterparty_guid
for both pickup and delivery. However, besides the customer profile, you can also use a terminal GUID for pickup and delivery. If you specified counterparty_guid
and omitted all other information, then all contact information will be automatically filled by the system. If the terminal doesn’t exist in the system and you want to save it to use it in other loads, you can set save_as_new
to true
.
Vehicles
Order’s vehicles are specified as an array. Make and model fields are required. However, it’s possible to automatically decode vehicle fields from VIN. If VIN is set while year, make, and model fields are left empty, the system automatically decodes and fills empty fields. For example, if VIN is 1FTFW1ET8CKD25036
then vehicle will be saved with the following field values:
|
|
Notice that not all fields were filled since the VIN decoder may not have full information about the vehicle.
Updating an order
There are two main endpoints to update existing orders: full and partial update. The full order update endpoint expects the whole order body as a payload. Each changed field should contain a new value while the rest should remain as is. For the partial order update endpoint you can pass only changed fields.
Full order update
You can update order using the following endpoint:
|
|
Order fields are described in API reference for the endpoint.
Warning
Please notice that any omitted field is treated as assigning NULL value to this field. Furthermore, if you don't include all vehicles into the payload, the missing ones will be removed from the order.
Partial order update
For the full order update endpoint, you have to send the whole order body as a payload even if you need to modify a single field. Unlike the full update endpoint, the partial update allows updating orders with the partial payload. The partial update is implemented according to the JSON Merge Patch standard proposed in RFC 7396.
To perform the partial update, you should send a payload with a set of fields that needs to be updated as an HTTP PATCH request. The content type of the request should be application/merge-patch+json
. Field values that are included in the payload replace old values. Fields that aren’t included in the payload remain untouched.
Notice that according to the standard, it is not possible to patch part of an array. For example, if you send a nested vehicles
array field in a payload, the order’s vehicle list will be completely overwritten by the content of this array.
You can partially update the order using the following endpoint:
|
|
Order fields are described in API reference for the endpoint.
Updating vehicles
Since order vehicles are included as an array, you can delete or update existing vehicles as well as add new ones while updating the order. Existing vehicles are distinguished from new vehicles by including vehicle GUID. In the above example, there are two vehicles in the vehicles
array field. The first vehicle has GUID, while the second doesn’t have it. Therefore the first vehicle will be updated while the second one added as a new one. If you omit vehicles from the payload, the missing ones will be removed from the order.
Sending a load offer
To dispatch a load, you should send a load offer to a carrier in Carrier TMS. You can send a load offer either to an existing (registered) or not yet registered carrier. In the former case, the carrier is identified by GUID; in the latter case, by USDOT number.
Sending a load offer to an existing carrier
You can send offer to an existing carrier using the following endpoint:
|
|
The carrier_guid
should contain the existing carrier GUID. This call generates a dispatch sheet, attaches it to the order, and changes the order status to pending
. The carrier will get email and SMS notifications. Once the carrier accepts the offer, the order status will be changed to accepted
.
The load offer details become available in the order’s active_offer
field. The load offer details can also be fetched using the following endpoint
|
|
Sending a load offer to a not registered carrier
You can send a load offer to a not registered carrier using the following endpoint:
|
|
Since this carrier isn’t registered in CTMS, the payload includes carrier_email
and carrier_phone
. If you don’t specify either of these fields, they will be fetched from FMCSA database. Notice, however, that FMCSA may not contain this information, or it may be outdated.
This call generates a dispatch sheet, attaches it to the order, and changes the order status to pending
. The carrier will get email and SMS notifications. Once the carrier accepts the offer the order status will be changed to accepted
and the carrier will be automatically registered in CTMS. In the future, you can send load offers to this carrier using GUID.
Cancel a load offer
Sometimes after sending a load offer, you may want to change order information or send a load offer to another carrier. Although the dispatch sheet is regenerated after each order update and reflects these changes in the revision section, some brokers still prefer to cancel and resend a new offer with a new dispatch sheet. In these cases, it’s possible to cancel a load offer that was sent to a carrier. After canceling an offer, you send another offer later.
You can cancel a load offer using the following endpoint:
|
|
This call sets the order status to canceled
and the active_offer
field to null
.
Fetching all offers
It’s possible to fetch the list of all offers which were sent for particular order. An order may have only one active offer but many canceled or declined offers. You can get the list of all load offers using the following endpoint:
|
|
The response structure is described in the API reference.
Manual order status change
After receiving and accepting a load offer, a carrier is responsible for updating the order status. Usually, the driver updates order status using the mobile app. Sometimes carrier dispatchers also update the load status using the carrier dashboard. However, as described in the introductory section above, sometimes you may want to update the order status manually before the carrier. For example, you may know that the order has already been picked up or delivered, but the driver hasn’t updated the order status yet. In such cases, you can change the order status manually.
Manually mark as accepted
You can mark a pending load offer as accepted using the following endpoint:
|
|
This call changes the order status to accepted
and sets is_status_changed_manually
field to true
.
Manually mark as picked up
You can mark an accepted load offer as picked up using the following endpoint:
|
|
This call changes the order status to picked_up
and sets is_status_changed_manually
field to true
.
Manually mark as delivered
You can mark a picked up load offer as delivered using the following endpoint:
|
|
This call changes the order status to delivered
and sets is_status_changed_manually
field to true
.
Manually mark as invoiced by carrier
You can mark a delivered load offer as invoiced by carrier using the following endpoint:
|
|
This call changes the order status to invoiced
.
Rollback manually changed status
It’s possible to rollback manually changed status to the status which was set by the carrier. For example, if the carrier accepted the order and you changed its status to delivered, then when you rollback the order status, it becomes accepted again. However, if the carrier marked the order as picked up after you manually changed the order status, rolling back would return the order to pick up status.
If the order was in pending status (i.e., the load offer wasn’t accepted by the carrier), the rollback endpoint wouldn’t return the order status back to pending. Instead, it would return it to accepted status.
You can rollback manually changed status using the following endpoint:
|
|
Canceling an order
Besides canceling a load offer, it’s also possible to cancel the order itself. The difference between canceling the offer and order is that in the former case, the order returns to the list of new orders, while in the latter case, the order is moved to a separate list in UI and won’t mix with the other orders. For example, the order can be canceled because the customer no longer wants to ship a load. You still can send a load offer for canceled offer.
You can cancel an order using the following endpoint:
|
|
This call changes the order status to order_canceled
.
Archiving an order
After delivering a load, you may no longer want to see it in your order list but retain historical data. To acheive this it’s possible to archive orders. Archived orders moved to a separate list in UI. You can unarchive the archived order if you want to.
You can archive an order using the following endpoint:
|
|
This call changes the order is_archived
field to true
.