Welcome!

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

        ...
    {
            "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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

        ...
        "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": "[email protected]",
            "first_name": "John",
            "last_name": "Doe"
        },
        ...

Some endpoints of Shipper API returned two fields: active and is_active.

The field active used to be marked as deprecated in the API reference and was removed.

Sometimes, webhook actions may not come through due to server failures.

Therefore, you may need to get the list of failed webhook actions for a particular date range.

The request takes two required parameters:

• start_date
• end_date

API reference: List of failed webhooks.

It is now possible to change some of the order's statuses manually.

Such actions as Mark as Accepted, Mark as Delivered, Mark as Picked Up, and Mark as Carrier Invoiced are available.

The reason behind having these options is because sometimes brokers need to change the order's status independent of the carrier.

• To Manually Mark Order as Accepted, you need to provide:

  carrier_email

  carrier_phone

  Broker primarily may use this option to mark order as accepted by internal carrier.

• To Manually Mark Order as Picked Up:

  The order must be in status accepted and you need to pass adjusted_date to adjust the pickup date.

• To Manually Mark Order as Delivered:

  The order must be in status accepted or picked up. To adjust the pickup and delivery dates, you need to pass adjusted_pickup_date and adjusted_delivery_date if order is in status accepted, and adjusted_delivery_date only if order is in status picked up.

• To Manually Mark Order as Carrier Invoiced:

  You need to pass adjusted_invoice_date to adjust the invoice date.

Deleting Internal Carriers is now available.

Internal carrier is the one created by shipper (please see Create a new internal carrier endpoint) and has carrier_type: "INTERNAL".

API reference: Delete an internal carrier.

Additional webhooks actions have been added.

Now it is possible to subscribe to the following webhooks:

• Event created when carrier sends a load request to shipper: load_request.created

• Carrier cancels their own load request: load_request.canceled_by_carrier

• Shipper declines carrier's load request: load_request.declined_by_shipper

API reference: Webhooks. Read more on Load Requests Webhooks here.

New endpoint to archive an order is now available. Order in any status can be archived, except for inactive orders.

If an order is posted to CD or SLB, it will be unposted once archived.

Please see archive an order endpoint.

The API endpoints are available that enables API customers to manage customers, terminals, and contacts with more flexibility. These endpoints are replacing the old (now deprecated) Contacts API. Customers and terminals can be reused while creating an order. Each customer or terminal can have several contacts. Only one contact can be marked as primary.

API reference: Customers, Terminals.

These changes add new fields to the Order object.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

        ...
        "pickup_counterparty_guid": "ef2818b8-a55e-436a-a61e-993ae0470928",
        "save_as_new": null,
        "save_as_new_contact": null
        "venue": {
          "name": "First Choice",
          "business_type": "DEALER",
          "address": "7997 Hudson Street",
          "city": "Suffolk",
          "state": "VA",
          "zip": "23434",
          "contact_name": "Patricia Bennett",
          "contact_title": "Dispatcher",
          "contact_email": "[email protected]",
          "contact_phone": "215-800-1859",
          "contact_mobile_phone": "412-452-2889"
        },
        ...

• pickup and delivery:
  • counterparty_guid to reuse customer or terminal information
  • save_as_new and save_as_new_contact to save customer, terminal, or contact information
• pickup.venue and delivery.venue:
  • business_type can accept the values DEALER, PRIVATE, AUCTION, REPO_YARD, PORT, BUSINESS
  • contact_title
  • contact_mobile_phone

API reference: create a new order.

Order has a new field now: purchase_order_number. By default it's null. It can be updated using the new endpoint.

Some endpoints of Shipper API return two fields: active and is_active. Both fields are boolean, and they indicate the object is active, not deleted.

active is deprecated now. API clients should use only is_active from now. We'll remove active from Shipper API on February 7, 2020. The field is marked as deprecated in the API reference already.

Currently our API works on two subdomains:

• api.broker.superdispatch.org
• api.shipper.superdispatch.com

We're going to shut down the first domain on January 31, 2020. After this date all requests should be sent to api.shipper.superdispatch.com. Our documentation and API reference already use the second domain.

The Contacts API endpoints in Shipper API shut down by January 31, 2020. They're deprecated now.

Currently our team are working on a more advanced feature that will replace Contacts. We'll make another announcement when the new API endpoints are ready.