This release is backward-compatible for existing REST integrations, with one exception (the retired Newtrul rate source, below). No endpoints or routes were removed, no response fields were removed, and authentication is unchanged.

Endpoints and fields that are built but not yet generally available are listed under Coming soon at the end of this page.

New: Accessorials, Documents, and Zip Code Lookup

Three lookups are now available on both the Broker and Customer scopes, so you can read reference data directly instead of maintaining your own copies.

Accessorials

GET /PublicApi/Broker/v2/Accessorials
GET /PublicApi/Customer/v2/Accessorials

Returns the accessorials configured for your organization.

Query parameters (all optional)

• customerId - Broker scope only; narrow the result to one customer.
• shipmentType - filter to accessorials valid for a shipment type.
• type - repeatable; filter by accessorial category.

Each entry returns: code, name, type, and shipmentTypes (the shipment types the accessorial applies to).

type is one of Shipment, Pickup, Delivery, Fuel, Insurance, Accounting, Rating, Lumper, Warehouse, Customs, Other.

Documents

GET /PublicApi/Broker/v2/Documents
GET /PublicApi/Customer/v2/Documents

Returns the documents attached to a shipment.

Query parameters

• shipmentId - required.
• attachmentType - optional; filter to a single document type.

Each entry returns: documentId, attachmentName, attachmentUrl, attachmentType, and accessLevel (Public, Private, or Admin).

attachmentType covers the full Tai document set - BOL, POD, Invoice, Carrier Bill, Carrier Confirmation, Packing List, Customs Entry Document, Scale Ticket, and others.

Zip Code Lookup

GET /PublicApi/Broker/v2/ZipCodeLookup
GET /PublicApi/Customer/v2/ZipCodeLookup

Resolves a postal code to a city and state.

Query parameters

• zipCode - required.
• country - optional; defaults to the US. Accepts any supported country name.

Returns: city, state, zipCode, country.

Do I need to do anything?

No. These are new endpoints.

Custom Shipment Reference Types - now fully manageable

POST /PublicApi/Organization/v2/CustomShipmentReferenceTypes
PUT /PublicApi/Organization/v2/CustomShipmentReferenceTypes/{id}
DELETE /PublicApi/Organization/v2/CustomShipmentReferenceTypes/{id}

You could already list custom shipment reference types. You can now create, update, and delete them, so an integration can manage a customer's reference-type configuration end to end.

Create and update

Request body (POST and PUT)

{
  "name": "Customer Project Code",
  "dataType": "String",
  "isShipment": true,
  "isStop": false,
  "isCommodity": false,
  "displayInFrontOffice": true,
  "displayInBackOffice": true,
  "customerOrganizationId": 12345
}

• name, dataType, and customerOrganizationId are required on create.
• dataType is one of Currency, Date, DateTime, Decimal, Email, Number, Phone, String, Link.
• On update, omitted fields are left unchanged.
• Both return the saved reference type.

Renaming a type backfills existing data. The new name is written to every existing shipment, stop, and commodity reference value that uses the type, in the same transaction. Historical records stay readable under the new name.

Delete

Returns 204 No Content. Existing reference values that use the type are preserved with their stored name and detached from the type definition, so no historical data is lost.

Access requirements

Same as the existing list endpoint:

• Customer-issued API keys are not permitted - 403 with {"error":"customer_api_key_not_authorized"}.
• The key's role must include TMS Site Admin, LSP Add/Edit, or IT Support Admin - otherwise 403 with {"error":"insufficient_role"}.
• A reference type outside your accessible set returns 404.

Master types are read-only

Master (broker-global) types cannot be created, modified, or deleted through this endpoint. Attempts return 403 with {"error":"cannot_modify_master_type"} or {"error":"cannot_delete_master_type"}.

Validation errors

400 responses carry an error code:

Do I need to do anything?

No. These are new endpoints.

Create Shipment - request payload streamlined

POST /PublicApi/Shipping/v2/Shipments

What changed

• shipmentId removed from the request body. It was never used when creating a shipment. If your payload still sends it, it is safely ignored.
• Simplified the per-stop address. Stops no longer accept shipmentStopPickupCommodities or shipmentStopDeliveryCommodities. Supply a shipment's commodities through the top-level commodities array. These per-stop fields were never processed on create; if your payload still includes them, they are safely ignored.

What did not change

• The Create Shipment response is unchanged.
• GET /PublicApi/Shipping/v2/Shipments/{shipmentId} still returns per-stop pickup and delivery commodities.

Rate sources - Newtrul retired, DAT - Convoy Marketplace added

Affects sourceType on spot quote requests, rate responses, and carrier insurance records.

What changed

• Newtrul has been retired and replaced by Highway TFX.
• DAT - Convoy Marketplace is a new rate source value.

Action required

• If you send sourceType, stop sending Newtrul and use Highway TFX instead.
• If you read sourceType, expect Highway TFX where you previously saw Newtrul, and tolerate the new DAT - Convoy Marketplace value.

Payment types - Convoy added

The value Convoy is now accepted and returned on:

• checkType (advance payments, bill payments)
• paymentType (invoice payments)
• preferredPaymentType (carrier create / update / read)

Action required

None. Additive. Consumers that switch on these values should tolerate Convoy.

Spot Quote - three new quote statuses

quoteStatus on truckload spot quotes now also accepts Expired, Standing, and Tendered.

Action required

None. Additive.

Shipment Reference Numbers - three new types

referenceType now also supports:

• Driver ETA
• External Carrier Confirmation Id
• Mileage to Next Stop

Action required

None. Additive. If you map referenceType values, add handling for the new types as needed.

Shipment Activity Logs - new activity type

Activity log type / activityType now also includes External Communications.

Action required

None. Additive.

Do I need to do anything?

• Most integrations: no action required. Everything above is additive except the Newtrul retirement.
• If you send or parse the Newtrul rate source: switch to Highway TFX.
• If you use a generated or typed SDK: regenerate it from the latest spec to pick up the new endpoints, the renamed Create Shipment request model, and the updated value sets.

Coming soon

These endpoints and fields exist in the spec but are not yet generally available. They are documented here so you can plan ahead. They are enabled per organization. Contact your Tai representative to request access. Do not build against them in production until access is confirmed.

Shipment Stop Alerts

Alerts can be read, raised, and resolved at the individual stop level, not just the shipment level. Calling these before your organization is enabled returns 404 Not Found.

Request body (both POST endpoints):

{
  "shipmentStopId": 123456,
  "shipmentAlerts": ["Shipment Delayed - Weather", "On Hand Origin"]
}

Both fields are required. shipmentAlerts values are the alert display names as they appear in Tai (for example On Hand Origin, Shipment Delayed - Driver, Delivery Refused by Consignee). All three endpoints return the stop's full alert list after the operation.

Notes and limits

• Each of the three endpoints is enabled independently, so read access and write access may arrive separately.
• Creating and resolving alerts additionally requires stop alerts to be enabled for your organization. Without it, the two POST endpoints return an error stating stop alerts are not enabled for this organization.
• The Incomplete Shipment alert cannot be added or resolved through the API.

Shipment alerts identify their stop

Alert objects gained an optional shipmentStopId field. It is populated only by the stop-level endpoints above; shipment-level alert reads leave it absent or null. The field is already present in the published schema, so typed clients will see it once they regenerate, whether or not stop alerts are enabled for you.

Get Shipment - richer response payload

GET /PublicApi/Shipping/v2/Shipments/{shipmentId}

Once enabled for your organization, this endpoint returns an expanded payload. No existing field is removed or renamed, and field types are unchanged. Until it is enabled, the response is exactly as documented today.

What gets added

• carrierRep - the carrier representative on the shipment: staffId, contactName, email, phone.
• Each entry in carrierList gains transitLegId and shipmentStopIds (the stops that carrier covers), so multi-leg shipments can be attributed per carrier.

One change worth planning for

referenceType becomes an open string. Everywhere reference numbers appear in this response - shipment, stop, and commodity level - referenceType is no longer restricted to a fixed list of values. This is what lets your custom shipment reference types (see above) come back through the API alongside the built-in ones.

All existing values remain valid and unchanged. But a response can now contain a reference type name that is not in the published list - specifically, any custom type you have defined.

If you deserialize referenceType into a strict enum or a closed set, handle unrecognized values before enabling this. Treat it as a string, or fall through to a default. Integrations that read referenceType as a plain string need no changes.