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
Connect Shipflow AI Operators with your Descartes TMS for request intake, shipment updates and exception handoffs through approved API, EDI or middleware routes.
Workflow-specific integration. Shipflow connects to Descartes through approved APIs, secure account access, file exchange or existing middleware—using the connection route that fits your environment and workflow.
Discuss your Descartes workflowYour systems. 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
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
Available connection routes.
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 the first deployment needs.
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
Descartes integration questions.
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.
How does Shipflow connect to Descartes?
The selected route can use the product’s documented API, EDI exchange or existing middleware. Shipflow maps that route to the required records, permissions and business acknowledgements for the workflow.
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.
Third-party product names belong to their respective owners. Available interfaces vary by product edition and account permissions.
Start with one workflow
Bring your workflow.
Keep your Descartes environment.
Define the first workflow, required system access, controls and acceptance criteria with Shipflow.
Book a working session