Electronic Dispatch to Carriers
Tender a load to a carrier electronically from the Tai TMS, and see what happens on accept, on reject, and over an API versus an EDI connection.
This article explains how the Tai TMS electronically dispatches a shipment to a carrier — how the request is triggered, what happens when the carrier accepts or rejects it, how to re-send a rejected dispatch, and how the two connection types (API and EDI) differ.
Overview
The Tai TMS can send a pickup request to a carrier electronically instead of you calling or emailing the carrier by hand. When a shipment is moved to the "Ready" stage, the system automatically tenders the load to the assigned carrier over that carrier's electronic connection. If the carrier accepts, the shipment moves forward and the system captures the reference numbers the carrier assigns (such as a pickup confirmation number and a PRO number). If the carrier rejects, the shipment is flagged so staff can react. This automation saves staff from manual dispatch calls and keeps the shipment's tracking numbers accurate.
How it works
Electronic dispatch is a side effect of advancing the shipment's status — you do not start it from a separate "dispatch" step the first time:
- You advance the shipment to Ready. Setting a shipment to the Ready stage (ready to tender to a carrier) signals the system to send the electronic pickup request to the assigned carrier. The same happens when a new shipment is created with a Ready status, or when saving an existing shipment changes its status to Ready.
- The system tenders the load. Behind the scenes, the Tai TMS builds the pickup request from the shipment's details — stops, commodities, accessorials, reference numbers, and service level — and sends it to the carrier over the carrier's connection. Only a shipment's linehaul leg and its delivery-local leg are dispatched this way.
- The carrier responds:
- Accepted → the shipment advances to Dispatched, and the reference numbers the carrier returns are saved onto the shipment: the pickup/confirmation number, the PRO number (when the shipment does not already have one), and a bill-of-lading number where the carrier provides one. Any documents the carrier returns are attached to the shipment automatically, and a private activity-log note records what was submitted and returned.
- Rejected or failed → the shipment is set to Sent, a "Rejected by Carrier" alert is added so staff notice it, and the carrier's error message is recorded in the shipment's private activity log.
- If no electronic connection is configured for that carrier, the system records in the shipment's activity log that dispatch is not available or configured for that carrier. This is a normal outcome, not an error with the shipment — it simply means dispatch for that carrier needs to be handled another way. For LTL shipments, the shipment screen also shows a notice, "Electronic dispatching is not available for this shipment," whenever the carrier has neither an API nor an EDI dispatch connection turned on, so you can see this before you try to dispatch.
- Re-sending a rejected dispatch. A shipment that carries the "Rejected by Carrier" alert shows a Dispatch Again button on the shipment screen. Choosing it re-sends the electronic dispatch to the carrier and reports success or the carrier's error codes and messages.
Carriers connect to the Tai TMS in one of two ways, and the connection type affects how quickly you get an answer:
- API connection — a direct, real-time link to the carrier. The pickup request and the carrier's response happen right away, so acceptance and the returned reference numbers typically come back within seconds.
- EDI connection — a standardized electronic-document exchange (an EDI load tender). It is queued and sent in batches rather than answered live, so it is slower. When a carrier has both an API connection and an EDI connection, the Tai TMS tries the API first and only falls back to an EDI load tender if the API attempt fails or returns no response (a carrier set up for EDI only goes straight to EDI).
Business rules & limits
- Dispatch is triggered by the Ready status. Moving a shipment to Ready is what launches the first electronic pickup request. Sent and Dispatched are results of that dispatch, not triggers. After a rejection, the Dispatch Again button on the shipment screen (shown while the shipment has the Rejected by Carrier alert) re-sends the request.
- Acceptance advances the shipment and captures reference numbers. When a carrier accepts over an API connection, the shipment moves to Dispatched and the pickup/confirmation number, PRO number, and any bill-of-lading number the carrier provides are recorded on the shipment automatically. The pickup number is saved as the carrier pickup number; for a delivery-local leg it is saved as the delivery carrier's PRO number instead.
- A successful re-dispatch of a shipment that is already Sent stays at Sent. The shipment only moves to Dispatched when it was earlier than Sent (Quote, Committed, or Ready) at the time of the attempt, so a successful Dispatch Again on a Sent shipment leaves it at Sent until staff advance it or the carrier's own updates arrive.
- Rejection is recoverable. When a carrier rejects a tender, the shipment goes to Sent status with a "Rejected by Carrier" alert, and staff can fix the issue and use Dispatch Again. A rejection does not silently disappear.
- EDI dispatch is slower than API dispatch (a real limitation). An API-connected carrier usually responds within seconds. An EDI-connected carrier goes through a queued exchange: the Tai TMS sends queued EDI tenders in batches roughly every ten minutes, and the carrier's EDI response then comes back on the carrier's own schedule. Because that acceptance is confirmed later rather than live, a load sent over EDI stays at Sent until the carrier's response arrives, instead of jumping straight to Dispatched the way an accepted API dispatch does. When the carrier's EDI response accepts the tender, the shipment moves to Dispatched and the carrier's pickup number (if the shipment does not already have one) and PRO number are saved; when the carrier declines it, the shipment is set to Sent and gets the Rejected by Carrier alert. Plan follow-up accordingly when a load is dispatched over EDI.
- A rejected API dispatch can still end up tendered over EDI. If an API dispatch fails and the carrier also has an enabled EDI connection, the shipment is tendered over EDI instead. Because the API failure is recorded first, the Rejected by Carrier alert can already be on the shipment even though the EDI tender went out.
- "Not available" is expected for carriers without a connection. If a carrier has no electronic dispatch set up, the system records that dispatch is not available or configured for that carrier, and an LTL shipment's screen shows the notice "Electronic dispatching is not available for this shipment." Those messages mean the carrier is not integrated for dispatch, and the load should be handled manually — it is not a failure of the shipment.
- Some carriers behave differently. A few carriers are intentionally left at Sent after a successful dispatch because their real status arrives later from the carrier, so a Sent shipment right after dispatch is not always a problem.
- Related steps follow a dispatch attempt. After a dispatch attempt, the system can carry out related steps such as recording the carrier's documents and reference numbers and handling insurance for the load.
Frequently asked questions
How do I dispatch a shipment to a carrier in the Tai TMS?
In the Tai TMS you dispatch a shipment by advancing it to the Ready stage. Setting the shipment to Ready automatically sends the electronic pickup request to the assigned carrier; there is no separate first-time dispatch button. The result is recorded on the shipment: its status, the carrier's reference numbers, a "Rejected by Carrier" alert if the carrier did not accept, and entries in the activity log.
What happens when a carrier accepts the dispatch?
In the Tai TMS, when the carrier accepts the tender over an API connection the shipment advances to Dispatched status and the system captures the reference numbers the carrier assigns — typically a pickup/confirmation number and a PRO number, and a bill-of-lading number where the carrier provides one. Any documents the carrier returns are attached to the shipment automatically.
What happens if the carrier rejects the load?
In the Tai TMS, if the carrier rejects the tender the shipment is set to Sent status and a "Rejected by Carrier" alert is added so staff can see it, with the carrier's error recorded in the activity log. Staff can then correct the shipment and use the Dispatch Again button to re-send it. The rejection is surfaced clearly rather than being hidden.
What is the difference between an API dispatch and an EDI dispatch?
In the Tai TMS, an API dispatch uses a direct real-time connection to the carrier, so acceptance and reference numbers usually come back within seconds. An EDI dispatch uses a standardized electronic-document exchange that is queued and sent in batches (about every ten minutes), with the carrier's response returning on its own schedule, so it is slower. Both accomplish the same goal — tendering the load electronically — but API is near-instant while EDI is not. If a carrier has both, the Tai TMS tries the API first and uses EDI only if the API attempt fails or returns nothing.
Why does my shipment say electronic dispatching is not available?
In the Tai TMS, the notice "Electronic dispatching is not available for this shipment" (shown on LTL shipments), or an activity-log entry saying dispatch is not available or configured for the carrier, means the assigned carrier has neither an API dispatch connection nor an EDI load-tender connection turned on, so the system cannot tender the load automatically. It is a normal, expected outcome rather than a problem with the shipment, and it means the load should be dispatched to that carrier by another method.
How long should I wait for a dispatch to be accepted?
In the Tai TMS the wait depends on the carrier's connection type. For an API-connected carrier, acceptance and the returned reference numbers are typically near-instant (within seconds). For an EDI-connected carrier, the tender is sent in a batch roughly every ten minutes and the carrier's response comes back on the carrier's schedule, so allow more time before assuming there is a problem.
Can I re-dispatch a shipment after a rejection?
Yes. In the Tai TMS, when a dispatch is rejected the shipment is set to Sent with a "Rejected by Carrier" alert, and a Dispatch Again button appears on the shipment screen. Staff can address whatever caused the rejection and choose Dispatch Again to send the load again. If the re-dispatch succeeds, the shipment stays at Sent (it only jumps to Dispatched from Quote, Committed, or Ready), so staff may need to advance the status afterward.
Why is my shipment still at Sent after the carrier accepted it?
In the Tai TMS a shipment stays at Sent after a successful dispatch when the dispatch went over EDI (acceptance arrives later in the carrier's EDI response), when the shipment was already at Sent before the attempt, or when the carrier is one that is deliberately left at Sent until its real status arrives. In each case the status moves on when the carrier's response or tracking updates arrive, or when staff advance it.