Shipment request intake
Structure an incoming order or booking request, check required fields and prepare a shipment record for the agreed Descartes process. Identify existing requests before proposing a new record.
Explore this workflowAI Operators · TMS
Shipflow for Descartes
Plan AI workflows around your Descartes TMS: request intake, shipment updates and exception handoffs. Confirm the product, API or EDI access and controls.
Configured for your environment. Available interfaces, accessible records and permitted actions depend on your product edition, account permissions and agreed workflow.
Discuss your Descartes workflowConfigured around your environment. Governed by your SOPs.
- Product first
- Identify the specific Descartes transportation product and enabled modules.
- Connection options
- Vendor-documented API connectivity and EDI messaging, subject to product scope.
- Workflow result
- Validated operational input or an approved, verified update to a matched record.
Where integration creates value
Turn unstructured requests into the next TMS action.
Transportation teams receive changes in emails, attachments and partner messages even when their core shipment record already exists in a TMS. Re-entering those details is only part of the work: someone also has to establish which shipment changed and whether the proposed action is permitted.
For Descartes, the integration discussion starts with the actual product. The name spans multiple solutions, so a capability documented for one should not be presented as coverage for the whole portfolio. Shipflow’s workflow design connects approved sources and the appropriate operational record after that boundary is established.
Workflow opportunities
Start with the work you want to complete.
Status-update preparation
Match carrier messages to the appropriate shipment and event. Separate a forecast from an actual milestone, and prepare updates only to the permitted fields.
Explore this workflowOperational exception handoffs
Gather the record, original message and discrepancy into one review context. Route missed appointments or unclear instructions to the responsible team.
Explore this workflowIllustrative workflow · subject to agreed scope
From a changed delivery request to an accountable handoff
Illustrative workflow: an incoming message asks to move a delivery appointment. The shipment is already planned and may need human review.
Identify the active shipment
Match approved references and the sender’s context. Distinguish a delivery change from a second request for a different movement.
Check the existing instruction
Compare dates, location and appointment information. Flag missing time zones or a change that conflicts with the active plan.
Prepare a bounded update
Present the proposed change and evidence to the authorized owner. Do not automatically reroute transport or notify unrelated parties.
Confirm the receiving outcome
Apply the approved update through the selected interface and check the resulting state. Keep a failed or ambiguous update open for resolution.
Connection approach
Confirm the interface before the promise.
Descartes Transportation Manager for Shippers publicly describes API connectivity and EDI messaging. This establishes possible integration approaches for that product, but the public overview is not a complete endpoint, authentication or object-permission specification.
For your environment, obtain the product-specific interface documentation and access requirements from the administrator or vendor. Confirm whether the proposed process uses an API, an EDI exchange or existing middleware. Record supported message versions, business acknowledgements and retry rules; do not invent a universal Descartes API.
Setup requirements
What we confirm with your team.
Named product and process
Confirm which Descartes solution is deployed, the business owner and the initial operational workflow.
Interface documentation and access
Obtain the supported API or message specification, authentication method, test access and any provisioning requirements.
Record and code mapping
Agree shipment references, partner codes, event meanings, time zones and which system owns each field.
Acknowledgement and recovery rules
Define how to verify acceptance, handle out-of-order messages and reconcile a write whose response was lost.
Control and rollout
Make access and accountability explicit.
Match before updating
Do not update a shipment from a similar customer name alone. Ambiguous references need human resolution.
Preserve the event’s meaning
An estimated arrival is not proof of delivery. Keep the source, event type and observation time with the proposed update.
Start with a limited scope
Measure correct matches, rejected updates and manual corrections for one team before enabling additional processes.
Common questions
Before connecting Descartes.
Does this cover every Descartes product?
No. Product names, interfaces and enabled modules must be verified. A TMS integration is not automatically a MacroPoint, customs or routing integration.
Do we need API access specifically?
Not necessarily. The appropriate route may be a documented API or an existing EDI or middleware exchange. It must support the required fields and completion checks.
Why are exact endpoints not listed here?
The reviewed public product material does not establish the endpoint contract for your deployment. That specification should come from the appropriate administrator or vendor.
Can the team review changes before submission?
Yes. Design the first workflow to prepare changes and route exceptions, with submission enabled only where both system permissions and operating policy allow it.
Product names identify the systems discussed. This page does not imply vendor certification, partnership or endorsement. Supported actions and the implementation scope are confirmed with your team.
Start with a defined scope
Bring your workflow.
Keep your Descartes environment.
Map the inputs, system access and approval boundaries with Shipflow. Agree on a useful first integration and how to verify its result.
Book a working session