Now it's possible to add vehicle sample photos into orders. These photos are displayed in Super Loadboard and Carrier TMS. Adding sample photos help carriers to book your orders and avoid unnecessary phone calls by revealing the custom equipment and actual condition of the vehicle.

Please see details in the API Reference.

Now the damages object includes a nested photos array with photo guid, file location as original_url, and taken_at datetime field.

    ...
    "photos": [
        {
            "guid": "eu281196-a55e-436a-a61e-993ae0440928",
            "original_url": "https://storage.googleapis.com/carrier-tms/media/carriers/eu281196-a55e-436a-a61e-993ae0440928/2021/4/20/example.jpg",
            "taken_at": "2019-11-15T10:33:29.112+0000"
        }
    ]

Please see the API reference.

So far as the processing time for pickup and delivery vehicle photos and inspections on driver's phone varies significantly depending on the amount of data and drivers' internet connection, an order's status is always updated prior to pdf BOL URL becomes available. Therefore, new webhook events are added which are triggered only when pickup or delivery BOL becomes available.

Please see the additional description.

Canceled orders have "status": "order_canceled". However, such orders are still active and can undergo a normal flow such as sending offer or posting to LBs. The status order_canceled is added to distinguish between ready orders (new) and the ones that were canceled by the customer or need a revision later on (order_canceled).

Please, see the API reference.

Webhooks for order and vehicle revisions allow getting notifications when an order or its vehicles are updated. Using these webhook events API users are able to fully synchronize data in their system with Shipper TMS. These events allow subscribing to any subset of field changes. For example, if you are interested only in price changes you can subscribe to the price field changes and get notified only when the order price is changed.

Please, see details in the Webhooks for order and vehicle revisions section of documentation and in API Reference.

With the PUT method for order update, we have to send the full representation of the resource even when we need to modify a single field. Unlike the PUT method PATCH method allows updating order with the partial payload. The partial update is implemented according to JSON Merge Patch standard proposed in RFC 7396.

In order to perform the partial update, you should send a payload with a set of fields that needs to be updated. 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 vehicle list in the order will be completely overwritten by the content of this array.

The following example demonstrates a partial update of price, pickup.scheduled_at, and delivery.scheduled_at fields:

    {
        "price": 123.99,
        "pickup": {
            "scheduled_at": "2020-12-22T10:33:29.112+0000"
        },
        "delivery": {
            "scheduled_at": "2020-12-28T10:33:29.112+0000"
        }
    }

Please, see details on how to use the HTTP PATCH method for partial order update from the API reference.

It is important for shippers to preserve agreed dates with the Customer in order to review carrier dates, changes, and build reports. Therefore, we added additional fields like scheduled_at_by_customer and scheduled_ends_at_by_customer which show the dates agreed with the Customer.

Additionally, from now on, carriers cannot change Pickup/Delivery dates set by shippers. Instead, changes to the dates will be stored in the readOnly scheduled_at_by_carrier field.

Please check out order request and response endpoints.

Added a vehicles object into the order's activity payload.

{
  "status": "success",
  "data": {
    "objects": [
      {
        "guid": "ee6a7af7-650d-499b-8e32-58a52ffdb7bc",
        "id": 0,
        "created_at": "2019-11-15T10:33:29.112+0000",
        "action_status": "SUCCESS",
        "carrier_address": "Main street, 5",
        "carrier_city": "Salt Lake City",
        "carrier_contact_name": "John Smith",
        "carrier_email": "example@email.com",
        "carrier_guid": "512cb41f-45f3-4996-83a5-83687bf0cc0b",
        "carrier_name": "string",
        "carrier_phone": "+1 234 5678 910",
        "carrier_state": "UT",
        "carrier_usdot": 123456,
        "carrier_zip": 84199,
        "code": "picked_up",
        "driver_name": "string",
        "driver_phone": "string",
        "error_details": "string",
        "error_message": "string",
        "status": "new",
        "user": {
          "guid": "ee6a7af7-650d-499b-8e32-58a52ffdb7bc",
          "is_active": true,
          "is_superuser": false,
          "created_at": "2019-11-15T10:33:29.112+0000",
          "changed_at": "2019-11-15T10:33:29.112+0000",
          "email": "user@example.com",
          "first_name": "string",
          "last_name": "string",
          "username": "string"
        },
        "vehicles": [
          {
            "guid": "ee6a7af7-650d-499b-8e32-58a52ffdb7bc",
            "lot_number": 1234,
            "make": "BMW",
            "model": "Gran Coupe",
            "vin": "1G8AL52F03Z157046",
            "year": 2012
          }
        ]
      }
    ],
    "pagination": {
      "total_pages": 0,
      "total_objects": 0,
      "limit": 20,
      "page": 0
    }
  }
}

This way it will allow shippers to track each particular vehicle better: when it is picked up or delivered.

Vehicles object is empty unless order is in status Picked up or Delivered.

Please, see the API reference on the per vehicle order activity.

Added new Approved Carrier status which is designed for shippers who want to monitor carrier compliance on their own.

Please, see the API reference how to get the list of Approved carriers.

API reference how to mark a carrier as Approved.

Please, read an article on Approved carriers.

The approved carrier object comes with the following properties:

        ...
    {
            "status": "success",
            "data": {
            "object": {
            "guid": "string",
            "usdot_number": "123456",
            "approved": true,
            "approved_since": "2019-11-15T10:33:29.112+0000",
            "preferred": false,
            "preferred_since": null,
            "in_blacklist": false,
            "in_blacklist_since": null,
            "insurance_certificate_holder": false,
            "insurance_certificate_holder_since": null,
            "insurance_cert_holder_file_url": null,
            "insurance_expires_at": null,
            "custom_external_id": "CARRIER-0098"
            }
        }
    }
        ...

We have added more details for the dispatcher user in the order's response payload.

The dispatcher object comes with the following properties:

        ...
        "dispatcher": 
        {
            "is_active": true,
            "created_at": "2019-11-15T10:33:29.112+0000",
            "changed_at": "2019-11-15T10:33:29.112+0000",
            "guid": "4f797316-63a8-432a-a4ef-2986b8occ89d",
            "username": "ZH058gvXGpyHwHQFbxLH",
            "email": "johndoe@mail.com",
            "first_name": "John",
            "last_name": "Doe"
        },
        ...