Subscribe to our release notes via RSS to get updates.

March 20, 2025

Payment Method & Payment Terms Validation and Vehicle Type Enhancements

1. Payment Method & Payment Terms Validation

  • Added validation rules to ensure only valid payment method & payment terms pairs can be used
  • Implemented stricter checks to prevent incorrect or unsupported payment combinations
  • Improved error handling with descriptive user feedback for invalid entries
Supported Payment Methods & Payment Terms Pairs
Payment MethodSupported Payment Terms
cashcash_on_pickup, cash_on_delivery, 2_days, 5_days
checkcheck_on_pickup, check_on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
cashiers_checkcheck_on_pickup, check_on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
money_ordercheck_on_pickup, check_on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
comchekcheck_on_pickup, check_on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
achon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
direct_depositon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
credit_cardon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
venmoon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
cashappon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
ushipon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
zelleon_pickup, on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
otherother, ach, cash_on_pickup, cash_on_delivery, quickpay, check_on_pickup, check_on_delivery, 2_days, 5_days, 7_days, 10_days, 15_days, 20_days, 30_days, 45_days, 60_days
Example Invalid Request
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
// Request
POST /v1/public/orders
{
  ...
  "payment": {
    "method": "cash",
    "terms": "10_days"
  }
  ...
}

// Response
{
  "status_code": 400,
  "error": "Invalid payment terms '10_days' for method 'cash'. Allowed terms are: [cash_on_pickup, cash_on_delivery, 5_days, 2_days]"
}

2. Vehicle Type Validation

  • Added vehicle.type as a mandatory field for all vehicle-related entries
  • Implemented validation rules to prevent incorrect vehicle type submissions
Supported Vehicle Types
  • sedan
  • 2_door_coupe
  • suv
  • pickup
  • 4_door_pickup
  • van
  • truck_daycab
  • truck_sleeper
  • motorcycle
  • boat
  • rv
  • heavy_machinery
  • freight
  • livestock
  • atv
  • trailer_bumper_pull
  • trailer_gooseneck
  • trailer_5th_wheel
  • other
Example Invalid Request
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
// Request
POST /v1/public/orders
{
  ...
  "vehicles": [
    {
      "type": "car"
    }
  ]
  ...
}

// Response
{
  "status_code": 400,
  "error": "Invalid vehicle type 'car'. Allowed types are: [sedan, 2_door_coupe, suv, pickup, 4_door_pickup, van, truck_daycab, truck_sleeper, motorcycle, boat, rv, heavy_machinery, freight, livestock, atv, trailer_bumper_pull, trailer_gooseneck, trailer_5th_wheel, other]"
}

General Improvements

  • Optimized API request validation for better data quality.
  • Updated API documentation to reflect the latest validation rules.
Migration Steps
  1. Ensure all API requests include valid payment.method and payment.terms pairs.
  2. Validate vehicle.type before submitting requests.
  3. Review API documentation for the updated validation rules.
Support

For assistance, contact [email protected].

February 26, 2025

Payment Method and Terms Improvements

We’ve enhanced our payment handling for Carrier API users to better distinguish between payment methods and terms. This update maintains backward compatibility with clearer payment fields.

What’s New

1. Updated Payment Structure
  • Added fields directly in the payment object:
    • payment_method: Specifies how payment is made (e.g., Cash, ACH, Credit Card)
    • payment_terms: Specifies when payment is due (e.g., 2 Days, On Delivery)
2. Backward Compatibility
  • The legacy payment.terms field will remain supported until April 30, 2025
  • All new integrations should use the updated payment object
  • Legacy terms will be automatically mapped to new fields
Deprecation Notice
Old FieldStatusReplacementDeadline
payment.termsDeprecatedpayment.payment_method and payment.payment_termsMay 30, 2025
Migration Steps
  1. Update requests to use new structure:
1
2
3
4
"payment": {
  "payment_method": "ach",
  "payment_terms": "2_days"
}
  1. Remove payment.terms from your implementation
  2. Test with both field formats during transition period

Updated API Documentation

Create Order

POST <base_url>/orders/

Request Body
1
2
3
4
5
6
7
8
{
  "...": "...",
  "payment": {
    "terms": "ach", // will be DEPRECATED - Use payment_details instead
    "payment_method": "ach",
    "payment_terms": "2_days"
  }
}
Payment Method Options
  • cash - Cash
  • check - Check
  • cashiers_check - Cashier’s Check
  • money_order - Money Order
  • comchek - Comchek
  • ach - ACH
  • direct_deposit - Direct Deposit
  • credit_card - Credit Card
  • venmo - Venmo
  • cashapp - CashApp
  • uship - UShip
  • zelle - Zelle
  • superpay - SuperPay
  • other - Other
Payment Term Options
  • on_delivery - On Delivery
  • on_pickup - On Pickup
  • cash_on_delivery - Cash on Delivery
  • cash_on_pickup - Cash on Pickup
  • check_on_delivery - Check on Delivery
  • check_on_pickup - Check on Pickup
  • quickpay - Quick Pay
  • 2_days - 2 Business Days
  • 5_days - 5 Business Days
  • 7_days - 7 Business Days
  • 10_days - 10 Business Days
  • 15_days - 15 Business Days
  • 20_days - 20 Business Days
  • 30_days - 30 Business Days
  • 45_days - 45 Business Days
  • 60_days - 60 Days
  • other - Other
Legacy Term Mapping
Legacy ValueNew MethodNew Term
achach(use payment_terms)
comchekcomchek(use payment_terms)
cash_on_pickupcashon_pickup
cash_on_deliverycashon_delivery
check_on_deliverycheckon_delivery
on_pickup(use payment_method)on_pickup
on_delivery(use payment_method)on_delivery
5_days(use payment_method)5_days
Full Example Request
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
  "driver_id": 1,
  "number": "ORDER-123",
  "payment": {
    "payment_method": "credit_card",
    "payment_terms": "7_days"
  },
  "customer": {
    "...": "..."
  },
  "...": "..."
}
Recommendations
1. Immediate Action
  • Begin using the updated payment object in all new order creations
  • Read from payment.payment_method and payment.payment_terms for order details
  • Update existing integrations by May 30, 2025
2. Monitoring
  • We’ll send reminder emails 30 days before deprecation
3. Support

February 14, 2025

New Escalation feature for Shipper-to-Broker flow

We have improved the Shipper-to-Broker flow by introducing the following features:

  1. New Endpoint for resolve escalation issues: Added an API endpoint to resolve escalation issues. Refer to the “Resolve Escalation” section in the Shipper-to-Broker flow API documentation.
  2. New Webhook for Escalation: A shipper can now subscribe to the webhook for escalation issues. The webhook will notify the shipper when an escalation issue has been submitted.

February 10, 2025

Improved Shipper-to-Broker Flow

We have improved the Shipper-to-Broker flow by introducing the following features:

  1. New Endpoint for Broker Listing: Added an API endpoint to retrieve a comprehensive list of linked brokers. Refer to the “Get linked brokers” section in the Shipper-to-Broker flow API documentation.
  2. Enhanced Load Offer Functionality: Updated the “Send load offer” endpoint to automatically populate broker-specific details. By utilizing carrier_guid={broker_guid} and carrier_type=BROKER, the system now auto-fills contact information and address details, streamlining the load offer process.
  3. Expanded Order Submission Capabilities: Modified the “Submit order to the broker” endpoint to provide greater flexibility. Previously, the endpoint allowed only one broker relation within the system. Now you can have multiple connections, and all you need to do is specify the broker_guid field with the GUID of the broker to whom you want to submit the order.

May 31, 2023

Added new SuperPay terms

SuperPay related updates

  1. SuperPay Payment Method:

    • payment.method field has been updated to support SuperPay. Set it as superpay to create or modify an order with SuperPay.
  2. SuperPay Payment Terms:

    • When using SuperPay (payment.method as superpay), payment.terms should be one of the following values:
      • 1_3_days - 1-3 Business days
      • 5_days - 5 Business days
      • 10_days - 10 Business days
      • 15_days - 15 Business days
      • 20_days - 20 Business days
  3. Temporary Usage of superpay Payment Terms:

    • Until August 1, 2023, superpay is still accepted as a value for payment.terms and be replaced with 1_3_days on our side.
    • Replace superpay with the appropriate replacement values before the deprecation deadline.

June 21, 2021

Vehicle sample photos

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.

April 20, 2021

Added damage photos for AIAG inspection

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

1
2
3
4
5
6
7
8
    ...
    "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.

February 23, 2021

Added webhooks for Pickup and Delivery BOL notifications

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.

February 4, 2021

Cancel Order endpoint

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 distiguish 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.

November 25, 2020

Webhooks for order and vehicle revisions

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.

November 18, 2020

Partial Order Update

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:

1
2
3
4
5
6
7
8
9
    {
        "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.

November 10, 2020

Additional Date Fields - Customer Pickup and Delivery Dates, Updates by Carrier Pickup and Delivery Dates

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.

October 13, 2020

Per vehicle order activity

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
{
  "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": "[email protected]",
        "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": "[email protected]",
          "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.

June 23, 2020

Added new Approved Carrier status

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"
            }
        }
    }
        ...

May 1, 2020

Added order's dispatcher's info into the order payload

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"
        },
        ...

March 20, 2020

Removed a deprecated "active" field

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.

February 21, 2020

Manual Flow

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.

January 21, 2020

Load Requests Webhooks

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 updates their own load request: load_request.updated

  • 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.

January 15, 2020

Archive Order

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.

December 27, 2019

Customer Portal: new API endpoints and new fields of the Order object

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.

December 5, 2019

The field "active" is deprecated

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.

December 5, 2019

Domain migration: api.broker.superdispatch.org --> api.shipper.superdispatch.com

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.