Order attachments now expose an is_location_protected boolean field. When true, the GPS location (geotag) metadata embedded in an uploaded photo is protected and not exposed. The field defaults to false.

You can set it when uploading an order attachment via the is_location_protected query parameter on POST /orders/{order_guid}/attachments, and it is returned on the attachment detail and list responses.

Shipper's Interest insurance is coming to the API, offered by Super Dispatch in partnership with Tint, our insurance provider. The endpoints serve two distinct purposes.

Quoting gets you an estimated price of coverage for one vehicle at a time, from its year, make, model and vehicle type plus the pickup and delivery locations. No order is involved, so you can quote at any point.

Policies on an order create draft policies for an order's vehicles and read back the insurance state. Completing checkout and managing the insurance afterwards happen in the Tint portal, which you reach through the personal_link the API returns. Webhooks tell you when a policy is issued or canceled, so you do not have to poll for those.

This is an additive change. No existing endpoint, field, or webhook action changes behavior.

New Endpoints​

Quoting does not require an order, so you can get an estimated insurance quote for a vehicle at any point — before the order exists, or once it is created but not yet picked up:

curl -X "POST" "https://api.shipper.superdispatch.com/v1/public/insurances/quotes" \
     -H 'Authorization: Bearer <access_token>' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "pickup": { "city": "San Francisco", "state": "CA", "zip": "94102" },
  "delivery": { "city": "Los Angeles", "state": "CA", "zip": "90001" },
  "vehicle": {
    "year": 2020,
    "make": "Honda",
    "model": "Accord",
    "vehicle_type": "sedan",
    "vin": "JHMZE2H73AS009608"
  }
}'

{
  "status": "success",
  "data": {
    "objects": [
      {
        "plan_slug": "shippers-interest",
        "calculated_premium": 47.79
      }
    ]
  }
}

New Webhook Actions​

insurance.issued is sent when the insurer issues a policy, carrying the issued premium and the portal link. insurance.canceled is sent when a policy ends, with a cancellation_reason.

A policy can be canceled as a side effect of editing an order — removing or changing an insured vehicle voids its policy — so insurance.canceled is not always the result of a deliberate cancellation. Check cancellation_reason rather than assuming.

What To Expect​

• vin is optional. Send it when you have it; a quote does not require one.
• The premium is estimated from the vehicle's declared value and the distance between pickup and delivery. Normally the insurer estimates that declared value itself from the vehicle details you send. Your value is a fallback, used only when it cannot arrive at a figure, not an override — so sending one does not always mean the premium quote is based on it.
• A quote can fail with 409 VEHICLE_VALUE_REQUIRED. This happens when the insurer cannot determine what the vehicle is worth and you supplied no value to fall back on. Retry with vehicle.value set.
• personal_link is null until a draft policy exists. GET .../insurance only reports the state it finds; it does not create anything. Call POST .../sync-insurance-policy first for an order that has never been quoted.
• sync-insurance-policy is rate limited to one call per order every 30 seconds. Calls inside that window return 429 RATE_LIMIT_EXCEEDED. The window is consumed even by a failed sync, so wait rather than retrying immediately.
• ZIP is optional on quotes. Supply city and state at minimum; that only generates the distance. A full address (building number, street, city) produces a more accurate premium, so the price matches when you proceed to purchase the insurance on Tint's platform.

API reference: Calculate an insurance premium, Get insurance details for an order, Sync insurance policy for an order. See the Webhooks documentation for full payload details.

The load_request webhook payload now carries a carrier_comment field. Carriers can attach a short note when sending or updating a load request, so you can weigh it before accepting the bid.

data.carrier_comment is a string limited to 160 characters.

{
  "action": "load_request.created",
  "order_guid": "823b7436-40d6-4039-bfe6-c7d90bd8c14d",
  "action_date": "2020-01-20T09:33:21.266+0000",
  "data": {
    "guid": "u789102t-f59k-j893-bfe6-c7d90bd8790f",
    "carrier_guid": "9b9fd584-800c-445d-81cb-c951daaeebcf",
    "requested_price": "12",
    "pickup_date": "2020-11-20T10:33:29.112+0000",
    "delivery_date": "2020-11-20T10:33:29.112+0000",
    "carrier_comment": "Can pick up a day earlier if the vehicle is ready."
  }
}

What To Expect​

• The field is delivered with all four load request actions: load_request.created, load_request.updated, load_request.canceled_by_carrier, and load_request.declined_by_shipper.
• carrier_comment is always present in the payload. When the carrier left no comment it is null, the same as the other data.carrier_* fields.
• This is an additive change: carrier_comment is a new key, and no existing field or value changes. If your integration validates payloads against a strict schema, allow the new key before the change ships.
• The comment belongs to the load request, not to the resulting order. It is not added to order.* webhook actions, and it does not appear on order responses after a request is accepted.

No other action is required. Existing integrations continue to work and can ignore the field.

See the Webhooks documentation for the full load request payload reference.

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 July 8, 2026.

Support​

For assistance, contact [email protected].

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 [email protected].

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 [email protected].