New webhook actions are now available in the public Shipper API for tracking when GPS tracking turns on or off for vehicles in transit:

Both actions carry a vehicle_guids array and a gps_active boolean indicating the new tracking state. Events are grouped per shipper, so a single notification may cover multiple vehicles.

See the Webhooks documentation for the full subscription flow and payload reference.

New webhook actions are now available in the public Shipper API for tracking driver-provided ETA updates and driver location:

See the Webhooks documentation for the full subscription flow and payload reference.

New Endpoint: Get Carrier ACH Details​

A new dedicated endpoint has been added to retrieve carrier ACH payment details:

GET https://api.shipper.superdispatch.com/v1/public/carriers/:guid/payment-methods/ach

This endpoint returns the carrier's ACH payment information including:

Example Response​

{
  "status_code": 200,
  "data": {
    "object": {
      "bank_name": "Chase Bank",
      "bank_routing_number": "***021",
      "bank_account_number": "***6789",
      "voided_check_url": null,
      "voided_check_url_available": true,
      "ach_last_update_date": "2026-03-15",
      "access_expires_in_days": 25
    }
  }
}

Note: bank_routing_number and bank_account_number will be masked unless there was a delivered order with ACH, Direct Deposit, or Other payment method within the last 30 days.

Breaking Change: ACH Info Removal from Carrier Responses​

What you need to do​

1. Migrate to the new GET https://api.shipper.superdispatch.com/v1/public/carriers/:guid/payment-methods/ach endpoint to retrieve ACH information.
2. Remove any dependency on the ach_payment field from other Carrier API responses before June 5, 2026.

Support​

For assistance, contact support@superdispatch.com.

1. Added 'superpay' to Payment Method & Payment Terms Validation​

• Added 'superpay' payment method to validation rules

Supported Payment Methods & Payment Terms Pairs​

Example Invalid Request​

Request: POST <base_url>/v1/public/orders

{
  "payment": {
    "method": "superpay",
    "terms": "45_days"
  }
}

Response:

{
  "status_code": 400,
  "error": "Invalid payment terms '45_days' for method 'superpay'. Allowed terms are: [1_3_days, 5_days, 10_days, 15_days, 20_days, 30_days]"
}

General Improvements​

• 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. Review API documentation for the updated validation rules.

Support​

For assistance, contact support@superdispatch.com.

We have improved the Escalation feature for the Shipper-to-Broker flow. A shipper can also subscribe to escalation.resolved webhook to receive update when the escalation was resolved.

We are introducing new public API endpoints for managing counter offers. Shippers can now create and cancel counter offers programmatically through the Shipper API.

This addresses the current limitation where these operations were only available via the Shipper TMS Web Application.

We have introduced the following features:

1. New Endpoint to Create a Counter Offer: Shippers can now programmatically submit a counter offer for a specific order request.

   • Endpoint: POST ${SHIPPER_API_URL}/v1/public/orders/{orderGuid}/requests/{requestGuid}/counter-offer
   • Request Body:

     {
       "price": 100.50
     }
     

   • Responses:
     • Success (HTTP 200 OK): Indicates the counter offer was successfully created with a pending status.

       {
         "status": "success",
         "data": {
           "object": {
             "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",
             "status": "pending",
             // ... other fields
           }
         }
       }
       

     • Existing Counter Offer (HTTP 409 Conflict): Returned if a counter offer already exists for the request.

       {
         "status": "fail",
         "data": {
             "message": "Only pending load request can be accepted",
             "error_id": "LOAD_REQUEST_ACCEPT_ERROR",
             "details": null
         }
       }
       

     • Validation Errors (HTTP 400 Bad Request): Returned if the request body fails validation (e.g., invalid price).

       {
         "status": "fail",
         "data": {
             "message": "Price can't be empty",
             "error_id": "VALIDATION_ERROR",
             "details": {
                 "price": ["Price should be a positive number", "Price should be a well-formed decimal number with maximum 2 digits as a fraction"]
             }
         }
       }
       

   Refer to the "Send a counter offer to the load request" section in the Shipper API documentation for full details.

2. New Endpoint to Cancel a Counter Offer: This endpoint allows shippers to cancel an existing active counter offer for a specified order request.

   • Endpoint: PATCH ${SHIPPER_API_URL}/v1/public//orders/{orderGuid}/requests/{requestGuid}/counter-offer/cancel
   • Responses:
     • Success (HTTP 200 OK): Indicates the counter offer was successfully found and its status updated to cancelled.

       {
         "status": "success",
         "data": {
           "object": {
             "is_active": true, // Note: is_active might become false after cancellation, depending on logic
             "created_at": "2019-11-15T10:33:29.112+0000",
             "changed_at": "2019-11-15T10:33:29.112+0000", // This would update
             "guid": "4f797316-63a8-432a-a4ef-2986b8occ89d",
             "status": "cancelled",
             // ... other fields
           }
         }
       }
       

     • Counter Offer Not Found (HTTP 404 Not Found): Returned if no active counter offer exists for the specified request.

       {
         "status": "fail",
         "data": {
             "message": "Offer not found.",
             "error_id": "COUNTER_OFFER_NOT_FOUND_ERROR",
             "details": null
         }
       }
       

   Refer to the "Cancel a counter offer for the load request" section in the Shipper API documentation for full details.

We believe these new API endpoints will significantly improve the flexibility and efficiency of managing counter offers for our shippers. Please review the updated Shipper API documentation for comprehensive details on implementation and usage.

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​

Example Invalid Request​

Request: POST <base_url>/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​

Request: POST <base_url>/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 support@superdispatch.com.

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.

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.

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.